connection dialog

Discussion of open issues, suggestions and bugs regarding UniDAC (Universal Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
Cogito
Posts: 24
Joined: Sat 05 Jul 2008 07:15

connection dialog

Post by Cogito » Wed 27 Jan 2010 10:54

Hello,

At runtime I don't know which database server is used, therefore I want to use the connection dialog component. But it is very annoying for a user to repeat the connection process for every start of application. What's best practice for this situation (please with short explanation of detail steps)? I think there should be a way to fully automate this complete connection process, for example storing connection values in registry, because it's often the same for every project.
In this context, is there a possibility to use the connection dialog which is available at design time, because it supports also the server specific options (for example, how to provide windows authentification for sql-server with the default connection dialog) ?

P.S. I can't decide which option depends on another option, for example, when I use windows authentication for sql server there's no need for a Username. For this case I know that but what about connections to other databases? I guess, there's really a need for a developer to get protected from all of these problems.

Dimon
Devart Team
Posts: 2910
Joined: Mon 05 Mar 2007 16:32

Post by Dimon » Fri 29 Jan 2010 15:20

To solve the problem you should use the TUniConnectDialog component that saves connection parameters in Registry. If you don't need to show this dialog more than one time in application, you can set the TUniConnection.LoginPrompt property to False after establishing connection.

Also you can use connection dialog at design time by double-clicking the TUniConnection component.

Cogito
Posts: 24
Joined: Sat 05 Jul 2008 07:15

Post by Cogito » Mon 01 Feb 2010 11:02

Dimon wrote:To solve the problem you should use the TUniConnectDialog component that saves connection parameters in Registry. If you don't need to show this dialog more than one time in application, you can set the TUniConnection.LoginPrompt property to False after establishing connection.

Also you can use connection dialog at design time by double-clicking the TUniConnection component.
Is it possible to get the information from ConnectDialog direct without registry and to define, for example, the provider name before opening the dialog?

Dimon
Devart Team
Posts: 2910
Joined: Mon 05 Mar 2007 16:32

Post by Dimon » Mon 01 Feb 2010 14:41

You can look at the example of customizing the UniDAC connect dialog in the ConnectDialog demo of UniDAC demo project.

Cogito
Posts: 24
Joined: Sat 05 Jul 2008 07:15

Post by Cogito » Tue 02 Feb 2010 08:16

Dimon wrote:You can look at the example of customizing the UniDAC connect dialog in the ConnectDialog demo of UniDAC demo project.
There's nothing shown about my problem. That's only a demonstration about using an own dialog class.
When I use the connection editor at design time from unidacconnection component it shows me a complete server list. How is it possible to get such a list at runtime (the connect dialog component shows only the local instance) ?

Dimon
Devart Team
Posts: 2910
Joined: Mon 05 Mar 2007 16:32

Post by Dimon » Tue 02 Feb 2010 15:11

You need to use your own ConnectDialog (by the example of UniDAC demo).
The TUniConnectDialog.GetServerLists method returns the server list.

Cogito
Posts: 24
Joined: Sat 05 Jul 2008 07:15

Post by Cogito » Wed 03 Feb 2010 07:51

Dimon wrote:You need to use your own ConnectDialog (by the example of UniDAC demo).
The TUniConnectDialog.GetServerLists method returns the server list.
As I said, the GetServerLists returns only the local server, but not all reachable server in the network (contrary to the connection editor at design time). Is there a possibility to get ALL available server exactly like the connection dialog at design time?

Dimon
Devart Team
Posts: 2910
Joined: Mon 05 Mar 2007 16:32

Post by Dimon » Thu 04 Feb 2010 09:49

To solve the problem set the TUniConnectDialog.UseServerHistory property to False and the TUniConnectDialog.Connection.Connected property to True.

Cogito
Posts: 24
Joined: Sat 05 Jul 2008 07:15

Post by Cogito » Fri 05 Feb 2010 15:34

This implementation with an own dialog class is no good idea, because I need only the values from uniconnection, for example, the server list or all possible databases etc...
I've a dialog with many fields and the connection parameters are only a few of these fields. I need also full access if and when fields should be enabled. Also, why are these parameters stored in registry?!
Why isn't that solved with methods, why in an own class implementation?
I guess the only solution for me is to use the default login dialog which is shown by a button and read the values from registry. Is it possible to predefine the connection dialog with values (for allow editing of an database saved connection) and where are these values stored?

Dimon
Devart Team
Posts: 2910
Joined: Mon 05 Mar 2007 16:32

Post by Dimon » Mon 08 Feb 2010 08:53

Dimon wrote:To solve the problem set the TUniConnectDialog.UseServerHistory property to False and the TUniConnectDialog.Connection.Connected property to True.
Why does this way not solve the problem?

Cogito
Posts: 24
Joined: Sat 05 Jul 2008 07:15

Post by Cogito » Mon 08 Feb 2010 14:56

Dimon wrote:
Dimon wrote:To solve the problem set the TUniConnectDialog.UseServerHistory property to False and the TUniConnectDialog.Connection.Connected property to True.
Why does this way not solve the problem?
Not this, I meant the complete way. For example how can I provide windows authentication for MS SQL Server with an own connection dialog?

Dimon
Devart Team
Posts: 2910
Joined: Mon 05 Mar 2007 16:32

Post by Dimon » Tue 09 Feb 2010 10:38

I did not fully understnad what you mean?
If you need to use windows authentication always, set appropriate option in runtime and use the standard connection dialog.
If you want to let user select authentication type, you should create own connection dialog.

Post Reply