Richard Wesley wrote:

> On Mar 6, 2006, at 03:54, The Wogster wrote:
>
>
>>So, why do you want to add a unneeded restriction to the user?
>
>
> If you are writing a connection dialog, the UI will look quite
> different to the user for these two options. The embedded version
> will only have a choose file control (for the database) and maybe a
> user name for table access authorisation. The server version will
> also have a server name, a uid/password pair (which must be
> validated) and a database name edit box (without a choose file
> option). Depending on your application, users might find such a
> dialog hard to navigate...
>

It depends on the application, for example I usually ask those questions
during application installation, stuffed the right answers to most of
those questions into the registry under the application, and allowing
changes in a configure or options menu item. Essentially leaving the
user with a username/password for login, if needed, if it wasn't needed
(for example embedded) then it skipped showing the login dialog all
together.

In one case there were actually two databases available test and
production, if you started the program normally you got production, if
you started it from a command line with --test you got the test database
(there was an option for --prod as well, but it wasn't needed, and they
never used it). It put (test) or (production) on the title line of the
application, so you knew which you were in, if you cared. Of course you
could create a shortcut to test as well.

Another application was designed so that the computer username, and the
database username matched up, again it stuffed most of the info into the
registry, Windows supplied the username, and passwords were assigned and
stored with the registry entries as an encrypted registry entry. I
think I used Blowfish on that one.... In this case the user didn't even
know that the database existed. The application looked after the
authentication. I actually preferred doing it this way, in that you
login to your workstation, and you don't need to remember 65,536
different usernames and associated passwords....

Another option, you create a special database, which has a generic user,
the application knows to login as the generic user (from it's registry
or even hard wired), connects to the special database, which contains a
couple of tables, one has a list of the other databases, along with the
access info, another has the OS username, database username and database
passwords (both are encrypted). It grabs the info for the specific user
(from the OS) then logs out and relogs in as the user. Giving the user
full database access under his own username and password. This works
better if the user could use one of a set of computers. A table could
be used in the special database as to what databases a specific user
has access to.

Just because generic utilities do things a specific way, doesn't mean
all applications need to. I listed some alternatives up above....

W