Make DBISQL/dbisqlc ask for credentials before trying to connect

[VolkerBarth]

As a follow-up to this question, I would like to ask for a better handling of connection attempts with incomplete credentials (aka UID/PWD combinations).

For common administration tasks, I usually have permanent links to dbisqlc/DBISQL with stored connection strings. Only the PWD is missing for security reasons.

So, when the connection is made, I'm aware that I have to complete my credentials. I usually will have to fill in the PWD - and in rare cases I might use a different UID and specify the according PWD. However, I wouldn't change the other connection parameters like ENG/SERVER, DBN and the like, as the database I'm about to connect to is given.

This is something that has irritated me since V5.5 days:

As dbisqlc/DBISQL will always try to connect, it will fail because of the missing PWD, and will return the well-known error "You supplied an invalid user ID or an incorrect password" (SQLCODE -103).

Well, in this particular situation, the message is somewhat wrong as I haven't entered any PWD at all (in contrast to a wrong one), and as such the connection must fail. This is not really an error, methinks.

And if both UID and PWD are missing, I get the inappropriate "Integrated logins are not permitted" error (SQLCODE -205). That's even more misleading, as I don't want to use an integrated login.

---

Therefore I'd like to suggest a new connection parameter (something like PROMPT_CREDENTIALS butter better worded...) that would change the connection process. It would display a login dialog and ask for UID/PWD before the connection attempt is made.

IMHO, the connection logic should be able to find out whether the given credentials are complete (i.e. if any of the connection string parameters, the DSN or SQLCONNECT contain a non-empty UID entry and a non-empty PWD/ENP entry). If not, and in case the according parameter is set, then the "Ask for credentials" dialog should be displayed.

(It could still be the common connection dialog but then all other fields should be read-only.)

(And it could also be used for the command line tools like DBBACKUP to prompt for credentials, but that's another story.)

It's a nice-to-have, obviously, and I can live with the current behaviour, but it might be more irritating for users who use DBISQL for regular administrative tasks.