Так добавляйте без дублей, через промежуточное звено - курсор без дублей, а не прямо из Excel в рабочую таблицу...

Да теперь понятно, почему так все происходит.
"Овсянников Владимир Николаевич" добавляется первым, затем опять "Овсянников Владимир Николаевич", потом валятся ошибки.
Хорошо.
Используя 5 буферизацию я добавляю записи, добавляем строки:
1
2
3
4 - здесь возникает ситуация когда записи дублируются (появляется второй Овсянников Владимир Николаевич, например запись 2)
делаем tablerevert()? Но тогда все записи (1,2,3) будут отменены?
Выходит, что 5 буферизацию в данном случае применять нельзя?
Или возвращать код ошибки, анализировать ее, если это ошибка дублирования записи делать tableupdate(), и переходить к следующей строке?

of63
Так добавляйте без дублей, через промежуточное звено - курсор без дублей, а не прямо из Excel в рабочую таблицу...

Хм, ну тогда зачем нужны такие CANDIDAT индексы.
В принципе хорошо работает и код с indexseek(), т.е. ищем ФИО, нашли - ничего не делаем, не нашли - добавили.

> зачем нужны такие CANDIDAT индексы
Чтобы ошибки генерить, при неправильном добавлении, наверное...

Перминов Игорь
делаем tablerevert()? Но тогда все записи (1,2,3) будут отменены?

У этой функции есть параметр вообще-то.

Перминов Игорь
Выходит, что 5 буферизацию в данном случае применять нельзя?

Какова цель применения буферизации в данном конкретном случае? Учитывая что работа идёт всё равно непосредственно с таблицей, что процесс не интерактивный (не ввод пользователем в контролы на форме)?
Применить то можно всё - вопрос в смысле. Для процедуры загрузки я такого не вижу. Если бы было нужно обеспечить загрузку "всё или ничего" (в случае любой ошибки всё вернуть в начальное состояние), то и тогда буферизация не поможет - нужна транзакция.

Перминов Игорь
В принципе хорошо работает и код с indexseek()

Он не работает в многопользовательской среде (точнее нужно будет так или иначе блокировать таблицу - чтобы "в процессе" никто не начал изменять данные). Для монопольно открытой таблицы, конечно, вполне можно и так делать - только код не будет "короче" да и индекс всё равно потребуется.

Igor Korolyov
Какова цель применения буферизации в данном конкретном случае?

Цель такова, чтобы исключить дубляж ФИО в БД.
Вообще это файлы для загрузки в СПО МОНИТОРИНГ, файлы заполняются в ручном режиме, там еще есть немного параметров.
Может быть, действительно, нет смысла в буферизации в данном конкретном случае...
Но Ньютон лежал под яблоней, и в результате был открыт закон всемирного тяготения (ну это так...)





Исправлено 1 раз(а). Последнее : Перминов Игорь, 01.11.17 18:04

Я спрашиваю конкретно про цель применения буферизации, а не просто "написания программы". Механизм предназначен прежде всего для целей написания устойчивых к сбоям многопользовательских графических интерфейсов.
Если напрямую открыв таблицу выполнить BROWSE и начать править записи, то во-первых фокс будет блокировать запись при НАЧАЛЕ редактирования - т.е. первом же нажатии кнопки которое что-то меняет в записи - естественно при этом делая редактирование этой записи невозможным для других пользователей. А во-вторых фокс будет записывать на диск "неполные" изменения - скажем если нужно поменять ФИО, адрес, возраст и семейный статус в 4 полях, то в процессе ввода этих данных в таблице будет "каша" - часть полей будут со "старыми" значениями, а часть с уже изменёнными. Кроме того, не будет никакой возможности отменить уже записанное в поле изменение - например если в самом конце ввода выяснится что 5-летний мальчик вдруг прописывается как "вдовец" - т.к. то что записано - оно уже записано, и "старого" значения для отката нет нигде. Всё будет работать точно так же и в гридах, и просто в текстбоксах которые "привязаны" к полям таблицы.

Эти проблемы возникали всегда, и потому в том же самом FPD где никакого механизма буферизации не существовало, его вручную "колхозили" сами прикладные программисты - для "однозаписного" ввода применяя набор переменных (привязывая GET поля к переменным, а не к полям таблицы), а для многозаписного - массивы или курсоры. Т.е. создавая "прослойку" между таблицей куда данные попадают "в готовом виде", и интерфейсом, где они могут находится в полу-готовом/рабочем виде.
А вот теперь скажи, какую цель преследует у тебя включение буферизации? Для чего нужно это самое промежуточное хранение в памяти полу-готовых данных перед их записью уже непосредственно на диск, в физический dbf файл?
Если кроме INSERT INTO ... VALUES (...) с соответствующими данными ничего более не производится, и если существующие в таблице (конечно не в присланном примере, т.к. там вообще ничего подобного нет) "правила и ограничения" вполне допустимо запускать СРАЗУ - в момент работы соответствующей команды INSERT INTO ... VALUES (...) - т.к. все возникшие "проблемы" поймает обработчик ошибок, то буферизация для этой таблицы в данной части кода совершенно не нужна, и даже вредит, т.к. реально "разделяет" момент ввода данных (INSERT) и момент срабатывания некоторых из проверок (заметь, не всех! "все" они будут работать только во время tableupdate, но вот "уникальность индекса" работает при попытке перехода с текущей записи).

Igor Korolyov
А вот теперь скажи, какую цель преследует у тебя включение буферизации?

1. Форма-список с персональными данными (ФИО, дата рождения, пол) с 5 буферизацией, эта информация хранится в таблице STUDENTS.
2. В таблице DOCUMENTS хранятся данные о выданных дипломах и их дубликатах, т.е. для одного СТУДЕНТА может быть несколько записей документов.
3. УЖЕ существует некоторое кол-во заполненных файлов-шаблонов, и чтобы не набирать персональные данные и некоторую другую информацию сделал их импорт из этих файлов-шаблонов (пока только в STUDENTS), но 5 буферизацию не отключил, надеялся на то, что используя индекс CANDIDAT дубляжа не получится.
4. В результате получил "грабли", с кучей ошибок, и как мы уже выяснили всего лишь из-за одной неверной записи и неправильного понимания как работает связка ИНДЕКС CANDIDAT и 5 буферизация.
5. Ручной ввод данных никто не отменял, поэтому думаю что, 5 буферизацию оставить нужно, отключать ее только при пакетной заливке из файла.
6. Отключив 5 буферизацию, при импорте из файла, получил вполне адекватный и правильный результат.

В одной и той же форме и ручной ввод и загрузка из внешнего источника? При том именно "пакетная"?

Тогда точно нужно работать не с самой таблицей, а с промежуточным курсором - лучше через курсорадаптер. "Уникальность" в этом случае остаётся лишь в таблице, и проверяться будет в момент "сохранения", а не в момент ручного ввода, или в момент "загрузки из экселя". В промежутке (до сохранения) в курсоре вполне себе будут и дубли, и записи нарушающие всякие там правила и ограничения (check-условия, триггера ссылочной целостности) наложенные на саму таблицу. Впрочем, они, эти "неправильные записи" останутся и после сохранения - как раз в "несохранённом" виде - позволяя уже самому пользователю решать что с ними делать - подправить и таки сохранить, или выкинуть/отменить. В таком случае полезным будет сделать в форме "визуализацию" - подсвечивать записи с несохранёнными изменениями. А если уж совсем хорошо делать, то ещё и ошибки возникшие при последней попытке сохранения записи рядом с ней же и показывать

Igor Korolyov
В одной и той же форме и ручной ввод и загрузка из внешнего источника? При том именно "пакетная"?

Нет не в одной форме.
Файлов со сведениями немного - 14 штук. В них содержатся сведения о выпускниках техникума, и заполнение из них это одноразовая операция - заполнить из них БД и все.
Работа по заполнению шаблона муторная - нужно заполнить кучу колонок и при этом правильно, например нужно писать Муж вместо муж.
Кроме этого конечный файл должен отвечать некоторым требованиям.
Вышел к руководству чтобы сделать некую БД + программку с помощью которой можно конечный файл делать автоматически и правильно.
Кроме этого образовательных учреждений в КО много, хочу предложить и им этот сервис.





Исправлено 1 раз(а). Последнее : Перминов Игорь, 03.11.17 04:24

Попробуйте так: