What I was trying to make was new feature with backward compatibility
and easy to use.
The idea of empty username *and* password, as standard Firebird are
using seemed good. First you don't need another new connection string
parameter. So you don't have to learn and know something new and also
no new code = no new bugs. :-)
Second it doesn't break backward compatibility (or at least it
shouldn't in my eyes). For normal server it's obvious. Username is
there, use it. Else try to negotiate trusted auth. For embedded server
it should be similar. As you're able to login with any
username/password only stuff left is permissions on database objects.
If you're using it, you're already using some username. If not, the
server gives you "all-the-power" login, so using sysdba will be the
same.
Also because I believe, that any real application isn't usign
hardcoded string, you can simply add username like sysdba [1] to your
connection string definition in app.config.
Conclusion:
* For a server, no change at all.
* For embedded
- if you're using some username, you're good (no matter whether the
username is here for easy switch to normal server, to apply some
specific database objects privileges or by accident)
- if not, you simply add sysdba username only into app.config, and you're done
PS1: As Helen said. Trusted auth is matter or server and server's
configuration. So even with connection string param, it will not force
server to use it.
PS2: I know, in some cases, changing the app.config will not be easy,
so simple replacement with new assembly will not work. But we have
also some changes in code to support new features (like transaction
params), thus you will maybe need to change the code anyway.
[1] The username is enough. Because to use trusted auth, provider need
both username and password to be empty.
Is the decision (and also solution for people not using username nor
password for embedded) clear?
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
