Пользовательский DSN и системный DSN — как выбрать систему?

Сценарий: наш установочный пакет используется для добавления пользовательского DSN. Мы изменили это, чтобы установить системные DSN из-за терминальных серверов и Citrix.

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

Я предполагаю, что мой вопрос заключается в том, есть ли способ заставить приложение использовать системный DSN вместо пользовательского DSN, если существуют дубликаты?

Наше приложение написано в PowerBuilder 10.5, и мы используем SQL Anywhere 10.0.1.

Спасибо, Кальвин


odbc powerbuilder dsn sqlanywhere
person Calvin Allen    schedule 13.02.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

См. RegistryValues() в справке PowerBuilder. Следующее не совсем то, что вам нужно, но оно показывает пару рабочих вызовов...

integer li_RC
string  ls_odbc_ini[]

li_RC = RegistryValues ( &
   "HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\ODBC Data Sources", &
    ls_odbc_ini )

IF li_RC <> 1 THEN
    MessageBox ( 'Error', &
        'RegistryValues failed in website.open' )
    RETURN
END IF

MessageBox ( 'A user DSN...', ls_odbc_ini[1] )

li_RC = RegistryValues ( &
   "HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI\ODBC Data Sources", &
    ls_odbc_ini )

IF li_RC <> 1 THEN
    MessageBox ( 'Error', &
        'RegistryValues failed in website.open' )
    RETURN
END IF

MessageBox ( 'A system DSN...', ls_odbc_ini[1] )

Другое предложение состоит в том, чтобы прочитать информацию о соединении с любого DSN, который вы хотите, а затем использовать соединение «без DSN», чтобы избежать «выбора неправильного DSN».

SQLCA.DBMS = 'ODB'

SQLCA.DBParm &
    = "ConnectString='Driver=SQL Anywhere 10;" &
    + "UID=dba;PWD=sql;DatabaseName=ruralfinds_local;EngineName=ruralfinds_local'," &
    + "ConnectOption='SQL_DRIVER_CONNECT,SQL_DRIVER_NOPROMPT'"

CONNECT USING SQLCA;

IF SQLCA.SQLCODE <> 0 THEN
    MessageBox ( 'Error', &
        'CONNECT failed in open:' &
        + '~r~nSQLCode = ' &
        + String ( SQLCA.SQLCode ) &
        + '~r~nSQLDBCode = ' &
        + String ( SQLCA.SQLDBCode ) &
        + '~r~n' &
        + SQLCA.SQLErrText )
    RETURN
END IF

Брек

person Breck Carter    schedule 14.03.2009

arrow_upward
3
arrow_downward

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

person Zoredache    schedule 14.02.2009
comment
Неплохая идея. У нас есть некоторые функциональные возможности, чтобы сделать это сейчас, но это требует от нас записи файла реестра, который мы затем запускаем через приложение. Думаю, я мог бы просканировать реестр на наличие действительного списка системных DSN и перед установлением соединения проверить, что не существует пользовательского DSN с таким же именем. - person Calvin Allen; 14.02.2009

arrow_upward
1
arrow_downward

Поскольку вы используете SQL Anywhere, обратите внимание на прилагаемую к нему утилиту dbdsn. Это позволит вам перечислять, описывать, создавать и удалять как пользовательские, так и системные DSN. Вы можете использовать его, например, чтобы увидеть, существуют ли пользовательские и системные DSN, и удалить тот, который вам не нужен.

person Graeme Perrow    schedule 12.08.2009