Галактика в вопросах и ответах

Добрый день!

Проблема такая:

Своим ард-отчетом в Галактику добавляю накладную и заполняю ее данными из dbf-файла.
Накладная большая - около 2500 записей.

Проявляется такая ситуация: после загрузки накладной, одна позиция в накладной отсутствует, т.е. в накладной идут по порядку записи 1546, а за ней сразу 1548. Смотрю журнал и вижу следующее: когда добавилась запись 1546, после этого Галактика у пользователя как будто висела 6 минут и добавилась уже сразу 1548 запись. И при чем Nrec, который должен был попасть на 1547 запись в таблице вообще отсутствует, такая запись не добавлялалсь в таблицу. И для 1548 записи Nrec уже следующий за тем Nrec, который должен был быть у записи 1547. Т.е. все-таки Галактика заняла Nrec для записи 1547, но запись так и не добавила.


Пробую повторно загрузить эту накладную - все загружается без проблем - все позиции загрузились.

Такая ситуация повторяется второй раз.

Получается, что дело не в данных, а в конкретной создавшейся ситуации на тот момент.
Как такое может быть? Пользователь, который загружает накладную, работает в терминале.
Может идеи какие-то есть?

возможно в этот момент кто-то добавлял спецификацию
nrec то в автомате генериться?
и отловите ошибку insert - если <>0 то выведите в протокол чего он там вернул.

Да, в этот момент работала еще куча пользователей: добавляли накладные, списывали большие накладные, редактировали счета-фактуры.
Получается, что мне надо проверять результат операции добавления?
Типа
IF (Insert... <> tsOK)
message('ошибка добавления');

Я правильно поняла?

Почитала документацию - там написано:
"В случае неудачного завершения операции модификации модификатор, не включенный в арифметическое выражение, САМ выдает сообщение об ошибке."
У пользователя уточнила: говорят да, была ошибка при загрузке, но смысл ее не помнят.
Теперь буду ждать, когда в очередной раз появится эта ошибка, чтобы своими глазами на нее посмотреть.

А в каких случаях возможна ошибка добавления записи?

например журнал был заблокирован на длинный срок.
опять же что за субд? если Pervasive и RandomSurrkeys<>on, то таблица surrkeys. Также могла не пролезть по уникальности индекса.
Ну или за отведенное время не смогли добавить запись из-за сбоя сети.
var www :word ;
www:=(insert )
if www<>0
{ message('Ошибка '+string(www))
}
а можно и зациклить пока вставка не пройдет все таки.

5 минут это они значиться сообщение не нажимали.
Вообще такие вещи нужно протоколировать тщательно -чтобы все исключительные ситуации отлавливать.

Понятно, edward_k! Спасибо!

база у нас MS SQL.
Индекс отпадает - т.к. повторно все загрузилось без проблем.
Вот сбой сети ... может быть.

Опять ошибка проявилась. Но теперь с другой таблицей, но суть ее одна и та же.
При загрузке накладной выдалась следующая ошибка:
Внутренная ошибка интерфейса доступа к БД. Таблица №1105 (SpDocNal). Подробности в ms70drv.log.

Смотрю в ms70drv.log:

Программа может работать некорректно
16.05.2008 11:36:15 [GALAXY#USER]:
DECLARE @CurDT DATETIME
SELECT @CurDT=GETDATE()
INSERT INTO T$SPDOCNAL(F$ATL_LASTUSER,F$ATL_ORIGINOFFICE,F$ATL_LASTDATE,F$ATL_LASTTIME,F$NREC,F$CSPDOC,F$CDOC,F$TIPDOC,F$CGRNAL,F$CNALOG,F$NALOG,F$SUMNAL,F$SUMVAL,F$SUMMA,F$CORG,F$VALCURSE,F$CROSCURSE) VALUES( ?,?,
CONVERT(INT,
SUBSTRING(CONVERT(BINARY(2),DATEPART(YY,@CurDT)),1,1)+
SUBSTRING(CONVERT(BINARY(2),DATEPART(YY,@CurDT)),2,1)+
CONVERT(BINARY(1),DATEPART(MM,@CurDT))+
CONVERT(BINARY(1),DATEPART(DD,@CurDT))),
CONVERT(INT,
CONVERT(BINARY(1),DATEPART(HH,@CurDT))+
CONVERT(BINARY(1),DATEPART(MI,@CurDT))+
CONVERT(BINARY(1),DATEPART(SS,@CurDT))+
CONVERT(BINARY(1),DATEPART(MS,@CurDT)/10)),?,?,?,?,?,?,?,?,?,?,?,?,?)
IF @@ERROR=0 AND @@ROWCOUNT>0 SELECT Sys#UL FROM T$SPDOCNAL WHERE F$NREC=?
16.05.2008 11:36:15 [GALAXY#USER]:
42000: [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot call napsrv.exe

Знатоки - Растолкуйте в чем суть ошибки?