>>'Cause I want to learn how to create and use named connections. :)
>>Or is this a feature that noone uses because its just too much trouble?
>
>It mostly is. First, it's stored in a dbc, which then means you need to set it up on the spot and store it in there - and then have everybody open the dbc every time they need to connect; open the whole dbc for a piece of string. Because a stored connection is just that, a packaged string stored in a table which is getting too many hits anyway. Besides, some workstations may have different requirements - so they'd need a different connection (maybe a different driver compatible with their OS version), or you may want to know which workstation is connecting, so you want a separate WSID field for each. Instead of setting up a connection record for each workstation (or any other way to give everyone their own connection), it's far easier to build the same string on the spot, from elements we have (we know the server name, the driver name is either fixed or stored in one global place, app name is unnecessary but can be global, user/pass is either windows authentication or stored per user etc). Most of the time it's quite possible to have the same string for everyone; I've usually kept it in an ini file or in as a text file for itself so it can be edited with notepad. The reason for this is user server migration, among other things - they refresh their hardware, reinstall OS, install new machines (sometimes for insurance reasons - nobody insures machines older than 5 years), so telling your app where to connect can be as easy as spending 15 seconds editing text. Also, if you need to distribute a new version of the dbc to your users... it can't contain the same connection for everybody, right? They're on different continents, worse, on different networks. So you can't just blindly copy the database, you need to rebuild the connection. With connectstring that you build on the spot there's no such problem.
>
>That's why :).

Thanks Dragan. That's helpful.
:)