lsgsoftware писал(а):Профессиональное решение - прямая работа с ODBC -наверное самое правильное ( на то Андрей -SQL-профи).Но во-первых это очень муторно, и во-вторых есть мнение, что возникнут проблемы с ODBC-драйвером MYSQL(велосипедисты скорее всего этот драйвер не тестировали).
Позволю себе не согласится с утверждением.
Во первых, что такое ODBC - это определённого рода стандард команд со стороны клиента - КЛИЕНТ - ODBC - СЕРВЕР
КЛИЕНТ-ODBC - стандарт
ODBC-СЕРВЕР - тут уже специфика соответсвующего ODBC драйвера, на которую нам обращать внимания не требуется т к нам это не надо, нам надо реализовать только связку КЛИЕНТ-ODBC.
Во вторых, на первый взгляд всех пугает это ODBC API, огромное количество функций, с кучей параметров, чтобы препарировать курсор необходимо сделать не один вызов ODBC API функций, НО стоит всё это один раз завернуть в базовые объекты и использование становится очень простым и гибким, Вы можете сделать любой запрос к БД без всяких ограничений, чего не скажешь про FILE,DRIVER('ODBC'), где чтобы сделать какое то нестандартное не первый взгляд действие но простое, приходится очень шибко извращаться, декларируя фальшивые таблицы в DCT.
lsgsoftware писал(а):
xxx{prop:sql}=' update table xxx set d=(select max(uid) from myfile);'
set(xxx);next(xxx)
и имеем xxx:d - идентификатор последней добавленной записи
Вроде все прозрачно, просто и работает
Коллеги, хотелось бы услышать Ваше мнение
ошыбочное решение, в многопользовательском режиме работы оно неправильное, т к с двух рабочих станций могут почти одновременно добавлять записи и послдедний SET NEXT вернёт не свой ID, а чужой, добавленный с другой рабочей станции.
Как я уже неоднократно говорил я за контролируемые процессы автонумерации, что это такое читайте на моём сайте.