Глюк с RecId

[Михаил Андреев]

М-да. Очень интересно. У меня то же самое наблюдается...
Сделал такой джобик:

static void Job5(Args _args)
{
    CustInvoiceLine         CustInvoiceLine;
    CustInvoiceTable        CustInvoiceTable;
    ;
    while select CustInvoiceLine
        join CustInvoiceTable
        where CustInvoiceTable.RecId == CustInvoiceLine.RecId
    {
        info( int642str( CustInvoiceLine.RecId));
    }
    
}

Его результаты:
Info Сообщение (13:18:15) 21426232134
Info Сообщение (13:18:15) 21426232135
Info Сообщение (13:18:15) 21426232136
Info Сообщение (13:18:15) 21426232137
Info Сообщение (13:18:15) 21426232138
Info Сообщение (13:18:15) 21426232139
Info Сообщение (13:18:15) 21426232140
Info Сообщение (13:18:15) 21426232141
Info Сообщение (13:18:15) 21426232142
Info Сообщение (13:18:15) 21426232143
Задумался..

[TasmanianDevil]

Цитата:

Сообщение от Михаил Андреев

Задумался..

Михаил, чесслово, не понимаю причин беспокойства
В какой-то момент времени значения счетчиков RecId у них сравнялись и было сделано подряд несколько однострочных клиентских накладных - только и всего, вполне вероятная ситуация (я 6 лет работал с системой, где почти все реляционные связи были на суррогатном 8-байтовом идентификаторе, генерируемом отдельно для каждой таблицы, там эта ситуация норма и проблем от этого не возникало).
Другое дело - разная скорость пожирания значений идентификатора в разных таблицах.
Вот если бы у вас было в значения пробелы - вот тогда надо задумываться.
CustInvoiceTable априорно более медленно или равно поедающая по сравнению с CustInvoiceLine.