PowerBuilder 12.5 Modified DataWindow не уточняет имена столбцов с владельцем таблицы

Я пытаюсь поддерживать программу PowerBuilder и не имею доступа к предыдущему программисту, написавшему код. Я изменил DataWindow, и теперь он генерирует исходный код, который НЕ включает владельца таблицы (dbo) в имена столбцов при выборе. Но он ДЕЙСТВИТЕЛЬНО включает dbo в предложение WHERE. Увидеть ниже.

(Старый исходный код показывает dbo.FieldAuxs везде в выборе и в том, где.)

retrieve="PBSELECT( VERSION(400) TABLE(NAME=~"FieldAuxs~" ) 
COLUMN(NAME=~"FieldAuxs.id~") 
COLUMN(NAME=~"FieldAuxs.clientid~") 
COLUMN(NAME=~"FieldAuxs.status~") 
COLUMN(NAME=~"FieldAuxs.historyear~") 
WHERE(    EXP1 =~"dbo.FieldAuxs.id~"   OP =~"=~"    EXP2 =~":al_id~" ) ) ARG(NAME = ~"al_id~" TYPE = number) " update="FieldAuxs" updatewhere=1 updatekeyinplace=no arguments=(("al_id", number)) )

Это приводит к ошибке: Префикс столбца dbo.FieldAuxs не соответствует имени таблицы или псевдониму, используемому в запросе...

Мой профиль базы данных регистрирует меня в среде разработки PowerBuilder как меня (не dbo). Я верю, что это то, чем я хочу заниматься.

Я читал о том, что для моего SQLCA.DBParm задано значение SQLQualifiers=1, но я не вижу области ввода DBParms в настройке профиля базы данных. Кажется, в некоторых версиях до 12.5 вы могли ввести значение DBParm прямо в какое-то поле. Но в 12.5 у них просто есть флажки и выпадающие списки, которые устанавливают значение для DBParm. И я не вижу выбора, который переводит в установку значения для SQLQualifiers. Согласно документации: SQLQualifiers=1 --Квалифицировать идентификаторы с именами владельцев в операторах SQL.

Я не должен правильно настроить что-то, что мой DataWindow автоматически генерирует исходный код, который полностью определяет имена столбцов ТОЛЬКО в предложении WHERE, а не в выборе.

Идеи приветствуются!


powerbuilder datawindow
person oscs    schedule 06.11.2012    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Проблема, которую вы описываете, является распространенной.

Типичная причина: разработчики используют разные идентификаторы пользователей базы данных в режиме разработки

Один разработчик входит в базу данных (в режиме разработки) как «владелец схемы», а другой разработчик входит в базу данных (в режиме разработки) как обычный пользователь (например, john_doe).

Как правило, разработчику следует избегать входа в систему в качестве владельца схемы при разработке или создании окон данных, особенно в базах данных с несколькими схемами, поскольку окна данных не будут работать, если пользователь запустит приложение под обычным идентификатором пользователя (не владельца схемы).

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

Когда PowerBuilder уточняет идентификаторы (из справки PB12.5)

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

Использование параметра базы данных SQLQualifiers (из справки PB12.5)

Этот параметр не работает для большинства баз данных. Согласно документации для PB 12.5, SQLQualifiers относится только к DIR Sybase DirectConnect.

Другие решения и примечания

Преобразование окна данных SQL в синтаксис будет работать, но я обычно стараюсь не делать этого, если в этом нет крайней необходимости. Причина, по которой вам не следует переходить на синтаксис, заключается в том, что вы теряете часть магии, встроенной в окно данных. Если вы работаете над приложением, которое поддерживает две или более внутренних баз данных, преобразование в синтаксис потребует создания отдельного набора окон данных для каждой СУБД. Например, рассмотрите синтаксис левого внешнего соединения для Oracle по сравнению с MS SQL Server, если закодировано в синтаксисе, окно данных будет работать в одной базе данных, однако, если оставить его в графическом режиме, PowerBuilder автоматически использует правильный синтаксис левого внешнего соединения на основе используемой СУБД. Есть много других преимуществ (магии), которые вы отрицаете при преобразовании в синтаксис, выходящий за рамки исходного вопроса.

person Rich Bianco    schedule 12.11.2012

arrow_upward
1
arrow_downward

Самое короткое решение — в SQL Painter для DataWindow перейти в меню Design / Convert to Syntax и самостоятельно вручную отредактировать синтаксис SQL. (Честно говоря, я нахожу графический редактор довольно ограничивающим и больше замедляет меня, чем помогает; обычно это один из моих первых шагов в создании DataWindow.)

Вероятно, есть советы и настройки, которые, как мне кажется, сильно зависят от СУБД (и я пока не вижу упоминаний о СУБД), например, назначение вашей учетной записи в качестве a владельца базы данных (dbo) соответствующей базы данных. , но приведенное выше поможет вам быстрее преодолеть текущую блокировку.

Удачи,

Терри.

person Terry    schedule 06.11.2012
comment
Спасибо. Я вручную отредактировал синтаксис SQL, и ошибка исчезла. Меня беспокоило, что я смогу добиться того же с художником. По мере того, как я лучше знакомлюсь с Powerbuilder, я надеюсь, что обрету уверенность в ручном редактировании таких вещей. Еще раз спасибо! - person oscs; 06.11.2012

arrow_upward
0
arrow_downward

Я не упомянул ранее, что мы недавно обновились до Powerbuilder 12.5 с 10.5. Это первый раз, когда окно данных было изменено после преобразования.

Сегодня я внимательно посмотрел в SQL Painter для этого окна данных и щелкнул вкладку «ГДЕ». В столбце было указано dbo.FieldAuxs.id (полное имя, указанное в предложении WHERE). Раньше я не понимал, что это раскрывающийся список, поскольку стрелка не отображается, пока вы не выберете этот виджет. Когда я бросил его, чтобы увидеть варианты, ни один из них не был полностью квалифицирован, т. Е. Ни один из них не имел префикса владельца таблицы dbo). Я выбрал FieldAuxs.id и сохранил окно данных. Теперь автоматически сгенерированный оператор выбора последовательно НЕ включает dbo. как префикс.

Похоже, что dbo.FieldAuxs.id был артефактом версии 10.5, когда бывший программист решил использовать полные имена столбцов в своем профиле базы данных.

person oscs    schedule 06.11.2012