дома › Мултимедија › Беше направен обид да се вметне не-уникатна вредност во уникатен индекс. Грешка: Обид да вметнете не-уникатна вредност во уникатен индекс: Microsoft SQL Server. Кога се префрлате од сметководствена професионална во корпоративна и не само што ги отстранувате не-уникатни индекси во датотека 1C 8

Беше направен обид да се вметне не-уникатна вредност во уникатен индекс. Грешка: Обид да вметнете не-уникатна вредност во уникатен индекс: Microsoft SQL Server. Кога се префрлате од сметководствена професионална во корпоративна и не само што ги отстранувате не-уникатни индекси во датотека 1C 8

Добивте порака што ги содржи линиите:
Microsoft OLE DB провајдер за SQL Server: Создадете уникатен индекс прекинат затоа што е пронајден дупликат клуч за ID на индекс
или
Не можам да_внесам дупликат клучен ред во објектот
или
Беше направен обид да се вметне не-уникатна вредност во уникатен индекс.

Решенија:

1. Во студиото за управување со SQL Server, ние физички го уништуваме неисправниот индекс (во мојот случај тоа беше индекс на табелата за вкупно сметководствени регистар). Во 1C ќе ги дистрибуираме неисправните документи. Во режимот за тестирање и корекција, проверете ги кутиите за реиндексирање на табелата + рекалкулација на вкупно. 1C повторно го создава индексот без грешка. Ние спроведуваме претходно неуспешни документи.

2. 1) Користејќи го Студиото за управување 2005 година, јас генерирав скрипта за создавање за да создадам индекс, кој беше кабриолет и го зачував во датотека.
2) Рачно го уби индексот Jamb од табелата _Accumrgtn19455
3) Покрена барање како
SQL код S_elect count(*), index_fields
ОД AccumRgTn19455
ГРУПА ПО index_поле
Имајќи брои(*)>1
Откако индексот беше убиен, имав прикажани 15 дупликати записи, иако пред чекор 2, барањето не врати ништо.
4) Поминав низ сите записи и рачно исчистив дупликати. Всушност, ја користев и обработката на „Структура на извештај“ за да разберам со што имам работа. Се покажа дека табелата _AccumRgTn19455 го складира акумулациониот регистар „Излез на производ (даночно сметководство)“. Направив и прашања за sql, идентификував 15 неуникатни документи и откако беа завршени сите активности, проверив во 1C дали овие документи се обработуваат нормално, без грешки. Се разбира, не треба само да ги чистите табелите по случаен избор: важно е да разберете што се чисти и како може да испадне.
5) Покрена барање за создавање индекс, кој беше зачуван во датотека.
6) Ја префрли базата на податоци во режим за еден корисник и го активираше dbcc checkdb - овој пат не беа генерирани грешки.
7) Ја префрли основата назад во режим за еден корисник.
Тоа е тоа... проблемот е надминат. Па, уште во 1C го започнав „Тестирање и корекција“, сè беше добро и таму, престанав да се жалам за неуникатен индекс.

3. Ако неединственоста лежи во датумите со нула вредности, тогаш проблемот се решава со креирање на база на податоци со параметар за офсет еднаков на 2000 година.

1. Ако проблемот е вчитување на базата на податоци, тогаш:
1.1. Ако вчитувате (со користење на dt-датотека) во базата на податоци на MS SQL Server, тогаш кога ја креирате базата на податоци, пред да ја вчитате, наведете го поместувањето на датумот - 2000 година.
Ако базата на податоци е веќе креирана со поместување 0, тогаш креирајте нова со 2000.

1.2. Доколку е можно да се работи со базата на податоци во верзијата на датотеката, тогаш извршете Тестирање и корекција, како и Конфигурација - Проверка на конфигурацијата - Проверка на логичкиот интегритет на конфигурацијата + Барање неточни врски.

1.3. Ако нема верзија на датотека, обидете се да вчитате од DT во верзија на клиент-сервер со DB2 (што е помалку барано за уникатност), а потоа извршете Тест и корекција, како и Конфигурација - Потврдете ја конфигурацијата - Проверете го логичкиот интегритет на конфигурацијата + Пребарајте неважечки референци.

1.4. За да го локализирате проблемот, можете да ги одредите податоците на објектот чие вчитување не успеа. За да го направите ова, треба да овозможите следење во алатката Profiler за време на подигање или да овозможите снимање во дневникот на настани на процесот DBMSSQL и EXCP.

2. Ако проблемот со неуникатноста се појави додека корисниците работат:

2.1. Најдете го проблематичното барање користејќи го методот во став 1.4.

2.1.2. Понекогаш се појавува грешка при извршувањето на барањата, на пример:

Оваа грешка се јавува поради фактот што во модулот за акумулациски регистар „Работно време на вработени во организации“ во постапката „Регистрирај се повторни пресметки“, услужниот збор „РАЗЛИЧНИ“ не е вклучен во барањето.
Код 1C v 8.x т.е. треба да биде:
Барање = Ново барање (
„ИЗБЕРЕТЕ РАЗЛИЧНИ
| Основни.Индивидуални,
. . . . .
Во најновите изданија на ZUP и UPP, грешката не се јавува, бидејќи пишува „РАЗЛИЧНИ“.

2.2. Откако ќе го пронајдете проблематичниот индекс од претходниот пасус, треба да пронајдете неуникатен запис.
2.2.1. Скрипта „Риба“ за идентификување на неуникатни записи користејќи SQL:
SQL код S_elect COUNT(*) бројач,<перечисление всех полей соответствующего индекса>од<имя таблицы>
ГРУПА ПО<перечисление всех полей соответствующего индекса>
КОЈ СЕ шалтер > 1

2.2.2 Пример. Индексот во грешката се нарекува „_Document140_VT1385_IntKeyIndNG“.
Список на полиња за табела:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393Ref, _Fld139Fld ld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRref, _Fld22261_TYPE26, _1Fld2_TYPE, _1Fld2
Пред да ја извршите постапката подолу, направете резервна копија од вашата база на податоци.
Стартувај во MS SQL Server Query Analyzer:
SQL код S_elect count(*), _Document140_IDRRef, _KeyField
from_Document140_VT1385
група по _Document140_IDRRef, _KeyField
имајќи број (*) > 1
Користете го за да ги дознаете вредностите на колоните _Document140_IDRRef, _KeyField, дупликат записи (ид, клуч).

Користејќи го барањето:
SQL код S_elect *
from_Document140_VT1385
или _Document140_IDRRef = id2 и _KeyField = key2 или ...
погледнете ги вредностите на другите колони од дупликатите записи.
Ако двата записи имаат значајни вредности и вредностите се различни, тогаш променете ја вредноста _KeyField да биде единствена. За да го направите ова, одреди ја максималната зафатена вредност на _KeyField (keymax):
SQL код S_elect max(_KeyField)
from_Document140_VT1385
каде _Document140_IDRRef = id1
Заменете ја вредноста _KeyField во еден од дупликатите записи со точната:
Ажурирање на SQL кодот _Document140_VT1385
поставете _KeyField = keymax + 1
Овде _LineNo1386 = е дополнителен услов кој ви овозможува да изберете еден од двата повторливи записи.

Ако еден (или двата) од дупликатите записи има очигледно неточно значење, тогаш треба да се отстрани:
Бришење на SQL кодот од _Document140_VT1385
каде _Document140_IDRRef = id1 и _LineNo1386 = lineno1
Ако дупликатните записи имаат исти вредности во сите колони, тогаш треба да оставите една од нив:
SQL код S_elect distinct *
во #tmp1
from_Document140_VT1385
каде _Document140_IDRRef = id1 и _KeyField = key1

Избриши од _Document140_VT1385
каде _Document140_IDRRef = id1 и _KeyField = key1

Вметнувам во _Document140_VT1385
S_изберете #tmp1

D_rop табела #tmp1

Опишаната постапка мора да се изврши за секој пар дупликат записи.

2.2.3. Втор пример:
SQL код S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Опис
ОД _Референца8_
ГРУПА ПО _IDRRef, _Опис
ИМАЊЕ (COUNT(*) > 1)

2.3.4 Пример за одредување на неуникатни записи со користење на барање 1C:Enterprise:
Код 1C v 8.x ИЗБЕРЕТЕ Директориум.Линк
ОД Директориум.Директориум AS Директориум
ГРУПА ПО Директориум.врска
СО КОЛИЧИНСТВО (*) > 1

Оваа статија ќе опише што да направите ако, кога работите со 1C: Enterprise 8.1, наидете на порака која ги содржи линиите:

Не може да се вметне дупликат клучен ред во објектот

Беше направен обид да се вметне неуникатна вредност во единствен индекс.

Што е индекс?

Индексите се структура која овозможува брз пристап до редови во табела заснована на вредностите на една или повеќе нејзини колони.
Индексот содржи копчиња, изградени од една или повеќе колони на табела или преглед, и покажувачи што мапираат до каде се чуваат наведените податоци.
Индексите ја намалуваат количината на податоци што мора да се прочитаат за да се врати збир на резултати.

Иако индексот е поврзан со одредена колона (или колони) од табелата, тој сепак е посебен објект на базата на податоци.

Индексите на табелите во базата на податоци 1C: Enterprise се креираат имплицитно при креирање на конфигурациски објекти, како и при одредени поставки на конфигурациските објекти.

Физичката суштина на индексите во MS SQL Server 2005 година.

Физички податоците се чуваат на страници од 8 Kb. Веднаш по креирањето, додека табелата нема индекси, табелата изгледа како куп податоци. Записите немаат специфичен редослед за складирање.
Кога сакате да пристапите до податоци, SQL Server ќе произведува скенирање на маса(скенирање на маса). SQL Server ја скенира целата табела за да ги најде записите што ги бара.
Оттука, основните функции на индексите стануваат јасни:
— зголемување на брзината на пристап до податоци,
— поддршка за уникатноста на податоците.

И покрај нивните предности, индексите имаат и голем број на недостатоци. Првиот е индекси заземаат дополнителен простор на дискоти во RAM меморија. Секој пат кога креирате индекс, ги складирате копчињата во опаѓачки или растечки редослед, кој може да има структура на повеќе нивоа. И колку е поголем/подолг клучот, толку е поголема големината на индексот. Вториот недостаток е операциите се забавуваатвметнување, ажурирање и бришење записи.
Во околината MS SQL Server 2005, се имплементираат неколку типови на индекси:

некластерирани индекси;
групирани (или групирани) индекси;
единствени индекси;
индекси со вклучени колони
индексирани погледи
целосен текст

Уникатен индекс

Единственоста на вредностите во индексираната колона е загарантирана со единствени индекси. Доколку се присутни, серверот нема да ви дозволи да вметнете нова вредност или да промените постоечка вредност на таков начин што како резултат на оваа операција се појавуваат две идентични вредности во колоната.
Уникатниот индекс е еден вид додаток и може да се имплементира и за кластерирани и за некластерирани индекси. Една табела може да има еден единствен кластериран индекс и многу уникатни некластерирани индекси.
Единствени индекси треба да се дефинираат само кога навистина е потребно. За да обезбедите интегритет на податоците на колона, можете да дефинирате ограничување на интегритетот УНИКАТЕН или ПРИМАРЕН КЛУЧ наместо да прибегнувате кон единствени индекси. Нивното користење исклучиво за да се обезбеди интегритет на податоците е губење на просторот во базата на податоци. Покрај тоа, времето на процесорот се троши и на нивното одржување.

1C: Enterprise 8.1, почнувајќи од верзијата 8.1, активно користи групирани уникатни индекси. Ова значи дека при конвертирање од 8.0 или мигрирање од 8.1.7 може да добиете неуникатна индексна грешка.

Ако неуникатноста лежи во датумите со нула вредности, тогаш проблемот се решава со создавање база на податоци со параметар за офсет еднаков на 2000 година.

Што да се прави?

1. Ако проблемот е вчитување на базата на податоци, тогаш:

1.1. Ако вчитувате (со користење на датотека dt) во базата на податоци на MS SQL Server, тогаш кога ја креирате базата на податоци, пред да ја вчитате, наведете го поместувањето на датумот - 2000 година.

Ако базата на податоци е веќе креирана со поместување 0, тогаш креирајте нова со 2000.

1.4. За да го локализирате проблемот, можете да ги одредите податоците на објектот чие вчитување не успеа. За да го направите ова, треба да овозможите следење во алатката Profiler за време на подигање или да овозможите снимање во дневникот за технолошки настани DBMSSQL и EXCP.

1.5. Ако јазолот (плановите за размена) е достапен, тогаш извршете ја размената. Можете исто така дополнително да го пополните ставот 2.3.5 пред да разменувате

2. Ако проблемот со неуникатноста се појави додека корисниците работат:

2.1. Најдете го проблематичното барање користејќи го методот во став 1.4.

2.1.2. Понекогаш се појавува грешка при извршувањето на барањата, на пример:

Оние. треба да биде:

Барање = Ново барање (
„ИЗБЕРЕТЕ РАЗЛИЧНИ
| Основни.Индивидуални,

Во најновите изданија на ZUP и UPP, грешката не се јавува, бидејќи пишува „РАЗЛИЧНИ“.

2.2. Откако ќе го пронајдете проблематичниот индекс од претходниот пасус, треба да пронајдете неуникатен запис.

2.2.1. Скрипта „Риба“ за идентификување на неуникатни записи користејќи SQL:
ИЗБЕРИ COUNT(*) бројач,<перечисление всех полей соответствующего индекса>од<имя таблицы>
ГРУПА ПО<перечисление всех полей соответствующего индекса>
КОЈ СЕ шалтер > 1

2.2.2 Пример. Индексот во грешката се нарекува „_Document140_VT1385_IntKeyIndNG“.

Список на полиња за табела:

Документ140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1393_TYPE, _Fld139Fld3,3RRFld_Fld1393_

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRref, _Fld22261_TYPE2, _1Fld2Ref, _Fld22261_TYPE2, _1Fld2

Пред да ја извршите постапката подолу, направете резервна копија од вашата база на податоци.
Стартувај во MS SQL Server Query Analyzer:

изберете count(*), _Document140_IDRRef, _KeyField
from_Document140_VT1385
група по _Document140_IDRRef, _KeyField
имајќи број (*) > 1

Користете го за да ги дознаете вредностите на колоните _Document140_IDRRef, _KeyField, дупликат записи (ид, клуч).

Користејќи го барањето:

изберете *
from_Document140_VT1385
или _Document140_IDRRef = id2 и _KeyField = key2 или…

погледнете ги вредностите на другите колони од дупликатите записи.

Ако двата записи имаат значајни вредности и вредностите се различни, тогаш променете ја вредноста _KeyField да биде единствена. За да го направите ова, одреди ја максималната зафатена вредност на _KeyField (keymax):

изберете макс (_KeyField)
from_Document140_VT1385
каде _Document140_IDRRef = id1

Заменете ја вредноста _KeyField во еден од дупликатите записи со точната:

update_Document140_VT1385
поставете _KeyField = keymax + 1

Овде _LineNo1386 = е дополнителен услов кој ви овозможува да изберете еден од двата повторливи записи.

Ако еден (или двата) од дупликатите записи има очигледно неточно значење, тогаш треба да се отстрани:

каде _Document140_IDRRef = id1 и _LineNo1386 = lineno1

Ако дупликатните записи имаат исти вредности во сите колони, тогаш треба да оставите една од нив:

изберете различно *
во #tmp1
from_Document140_VT1385
каде _Document140_IDRRef = id1 и _KeyField = key1

избришете од _Document140_VT1385
каде _Document140_IDRRef = id1 и _KeyField = key1

вметнете во _Document140_VT1385
изберете #tmp1

фрли табела #tmp1

Опишаната постапка мора да се изврши за секој пар дупликат записи.

2.2.3. Втор пример:

ИЗБЕРЕТЕ БРОЈ (*) AS Expr2, _IDRRef AS Expr1, _Опис
ОД _Референца8_
ГРУПА ПО _IDRRef, _Опис
ИМАЊЕ (COUNT(*) > 1)

2.3.4 Пример за одредување на неуникатни записи со користење на барање 1C:Enterprise:

или за сметководство

ИЗБЕРЕТЕ
Подпрашање.Период,
Подпрашање.Рекордер,
<измерения>,
SUM(Subquery.Number of Records) AS Број на записи
ОД
(ИЗБЕРЕТЕ
Самоподдржувачки. Период AS период,
Самоподдржувачки. Регистратор АС Секретар,
<измерения>,
1 AS Број на записи
ОД
Регистар за сметководство.Самоподдржувачки AS Самоподдржувачки) AS Subquery

ГРУПА ПО
Подпрашање.Период,
Подпрашање.Рекордер,
<измерения>

ИМАЊЕ
SUM(Подпрашање.Број на записи) > 1

2.3.5 Направете го subd индексот неединствен. Скрипирајте го индексот користејќи го Менаџмент Студио.

2.3.6 Посебен случај при размена во RDB. Грешката се јавува во „помошни“ табели поврзани со пресметката на збирот или аналитиката. На пример:

Грешка при повикување на методот на контекст (Write): Обид да се вметне неуникатна вредност во единствен индекс:
Microsoft OLE DB провајдер за SQL Server: Не може да се вметне дупликат клучен ред во објектот „dbo._AccntRegED10319“ со единствен индекс „_Accnt10319_ByPeriod_TRNRN“.
HRESULT=80040E2F, SQLSrvr: состојба на грешка=1, сериозност=E, мајчин=2601, линија=1

Во овој случај, пред да се вчита, исклучете ја употребата на збирки, вчитајте ја пораката, овозможете употреба на збирки и повторно пресметајте.

Добивте порака која ги содржи линиите:
Microsoft OLE DB провајдер за SQL Server: Создадете уникатен индекс прекинат затоа што е пронајден дупликат клуч за ID на индекс
или
Не можам да_внесам дупликат клучен ред во објектот
или
Беше направен обид да се вметне не-уникатна вредност во уникатен индекс.

Решенија:

1. Во студиото за управување со SQL Server, ние физички го уништуваме неисправниот индекс (во мојот случај тоа беше индекс на табелата со вкупни збирки на сметководствените регистри). Во 1C ќе ги дистрибуираме неисправните документи. Во режимот на тестирање и корекција, штиклирајте ги полињата за реиндексирање на табели + повторна пресметка на збирки. 1C повторно го создава индексот без грешка. Ние спроведуваме претходно неуспешни документи.

2. 1) Користејќи го Менаџмент Студио 2005 година, генерирав скрипта за креирање за да креирам индекс, кој беше кабриолет, и го зачував во датотека.
2) Рачно го уби заглавениот индекс од табелата _AccumRgTn19455
3) Покрена барање како
SQL код S_elect count(*), index_fields
FR OM AccumRgTn19455
ГРУПА ПО index_поле
Имајќи брои(*)>1
Откако индексот беше убиен, имав прикажани 15 дупликати записи, иако пред чекор 2 барањето не врати ништо.
4) Поминав низ сите записи и рачно исчистив дупликати. Всушност, ја користев и обработката на „Структура на извештај“ за да разберам со што имам работа. Се покажа дека табелата _AccumRgTn19455 го складира акумулациониот регистар „Излез на производ (даночно сметководство)“. Направив и прашања за sql, идентификував 15 неуникатни документи и откако беа завршени сите активности, проверив во 1C дали овие документи се обработуваат нормално, без грешки. Се разбира, не треба само да ги чистите табелите по случаен избор: важно е да разберете што се чисти и како може да испадне.
5) Покрена барање за создавање индекс, кој беше зачуван во датотека.
6) Ја префрли базата на податоци во режим за еден корисник и го активираше dbcc checkdb - овој пат не беа генерирани грешки.
7) Ја префрли основата назад во режим за еден корисник.
Тоа е тоа... проблемот е надминат. Па, уште во 1C го започнав „Тестирање и корекција“, сè беше добро и таму, престанав да се жалам за неуникатен индекс.

3. Ако неединственоста лежи во датумите со нула вредности, тогаш проблемот се решава со создавање база на податоци со параметар за офсет еднаков на 2000 година.

1. Ако проблемот е вчитување на базата на податоци, тогаш:
1.1. Ако вчитувате (со користење на dt-датотека) во базата на податоци на MS SQL Server, тогаш кога ја креирате базата на податоци, пред да ја вчитате, наведете го поместувањето на датумот - 2000 година.
Ако базата на податоци е веќе креирана со офсет 0, тогаш креирајте нова со 2000 година.

2. Ако проблемот со неуникатноста се појави додека корисниците работат:

2.1. Најдете го проблематичното барање користејќи го методот во став 1.4.

2.1.2. Понекогаш се појавува грешка при извршување на прашања, на пример:

Оваа грешка се јавува поради фактот што во модулот за акумулациски регистар „Работно време на вработени во организации“ во постапката „Регистрирај се повторни пресметки“, услужниот збор „РАЗЛИЧНИ“ не е вклучен во барањето.
Код 1C v 8.x т.е. треба да биде:
Барање = Ново барање (
„ИЗБЕРЕТЕ РАЗЛИЧНИ
| Основни.Индивидуални,
. . . . .
Во најновите изданија на Zup и UPP, грешката не се јавува, затоа што пишува „РАЗЛИЧНИ“.

2.2. Откако ќе го пронајдете проблематичниот индекс од претходниот пасус, треба да пронајдете не-уникатен запис.
2.2.1. Скрипта „риба“ за идентификување на не-уникатни записи со употреба на SQL:
SQL код S_elect COUNT(*) бројач,<перечисление всех полей соответствующего индекса>од ом<имя таблицы>
ГРУПА ПО<перечисление всех полей соответствующего индекса>
КОЈ СЕ шалтер > 1

2.2.2 Пример. Индексот во грешката се нарекува "_document140_vt1385_intkeyindng".
Список на полиња за табела:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393Ref, _Fld139Fld ld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRref, _Fld22261_TYPE26, _1Fld2_TYPE, _1Fld2
Пред да ја извршите постапката подолу, направете резервна копија на вашата база на податоци.
Стартувај во MS SQL Server Query Analyzer:
SQL код S_elect count(*), _Document140_IDRRef, _KeyField
fr om _Document140_VT1385
група по _Document140_IDRRef, _KeyField
имајќи број (*) > 1
Користете го за да ги дознаете вредностите на колоните _Document140_IDRRef, _KeyField, дупликат записи (ид, клуч).

Користејќи го барањето:
SQL код S_elect *
fr om _Document140_VT1385
каде _document140_idrref = id1 и _keyfield = key1 или _document140_idrref = id2 и _keyfield = key2 или ...
погледнете ги вредностите на другите колони од дупликатите записи.
Ако двата записи имаат значајни вредности и вредностите се различни, тогаш променете ја вредноста _KeyField да биде единствена. За да го направите ова, одреди ја максималната зафатена вредност на _KeyField (keymax):
SQL код S_elect max(_KeyField)
fr om _Document140_VT1385
wh ere _Document140_IDRRef = id1
Заменете ја вредноста _KeyField во еден од дупликатите записи со точната:
Ажурирањето на SQL кодот го јадеше _Document140_VT1385
поставете _KeyField = keymax + 1

Овде _LineNo1386 = е дополнителен услов кој ви овозможува да изберете еден од двата повторливи записи.

Ако еден (или двата) од дупликатите записи има очигледно неточно значење, тогаш треба да се отстрани:
Бришење на SQL кодот од _Document140_VT1385
wh ere _Document140_IDRRef = id1 и _LineNo1386 = lineno1
Ако дупликатните записи имаат исти вредности во сите колони, тогаш треба да оставите една од нив:
SQL код S_elect distinct *
во #tmp1
from_Document140_VT1385

Избриши од _Document140_VT1385
wh ere _Document140_IDRRef = id1 и _KeyField = key1

Вметнувам во _Document140_VT1385
S_изберете #tmp1

D_rop табела #tmp1

Опишаната постапка мора да се изврши за секој пар дупликат записи.

2.2.3. Втор пример:
SQL код S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Опис
ОД _Референца8_
ГРУПА ПО _IDRRef, _Опис
ИМАЊЕ (COUNT(*) > 1)

Информации земени од страницата

Решенија: