Возвращаемое значение динамического оператора SQL с использованием текущего целевого соединения - PullRequest
0 голосов
/ 16 августа 2011

В настоящее время я создаю свой первый настоящий проект в Pervasive.Задача состоит в том, чтобы сопоставить определенную структуру XML, содержащую заказы (как в магазинах и продуктах), с 3 таблицами, которые я создал сам.Эти таблицы находятся внутри экземпляра MS-SQL-Server.

Все таблицы имеют уникальный ключ с именем «id», автоматически увеличивающийся столбец.Я удалил этот столбец из всех отображений, чтобы Pervasive не пытался заполнить его сам.

Для определенных вычислений, для ключа разделения в одной из таблиц и для ссылок на созданные записи в других таблицах,Мне понадобится идентификатор, который база данных только что создала.За это я погуглил ответ.Я могу использовать «выберите @@ identity;»в качестве оператора, и это возвращает идентификатор, который был недавно создан для текущего соединения.Это означает, что в Pervasive мне придется выполнить этот оператор, используя уже существующий целевой объект соединения.

Но как это сделать?Я совершенно уверен, что мне понадобится объект JDImport или DJExport, но как получить объект, связанный с текущим соединением, с помощью которого Pervasive вставляет записи?нужно ссылаться на идентификатор в других таблицах?

Ответы [ 2 ]

0 голосов
/ 12 октября 2011

Если кто-то ищет этот пост и интересуется ответом, это «Вы не можете».Pervasive не разрешает доступ к своему собственному объекту соединения, который они используют для запроса к базе данных.Без доступа к нему вы не сможете гарантированно получить правильный идентификатор.Решение для нас заключалось в следующем: мы использовали хранимую процедуру, которую мы вызвали в событии Before-Transformation, которая создала запись заголовка и вернула идентификатор и необязательное сообщение об ошибке в виде таблицы.Мы выполнили его, и он возвращает идентификатор, который мы затем сохраняем и используем в нашем отображении.

0 голосов
/ 17 августа 2011

Не уверен, как все работает в Pervasive, но у вас могут возникнуть проблемы с @@ identity ,. Scope_identity (), вероятно, будет безопаснее, но все еще может не работать в Pervasive.

Надеемся, что у ваших таблиц есть естественный ключ в дополнение к сгенерированному идентификатору, и в этом случае вы можете выбрать свой идентификатор на основе естественного ключа. Это позволит избежать любых проблем, которые могут возникнуть у вас с разными сеансами и областью действия.

...