Is it possible to loop through the strongly typed TableAdpaters in aDataSet.

[John Heitmuller.]

I’m using VisualStudio 2008. My original problem is that I need to
change the database user login name in my application connection
string at runtime. I have to maintain an audit able of user actions
on the database, so I need to know who is running the application.

My thought was in the form_load() I would read the application
ConenctionString. Replace the generic DB login name with the user’s
login name. I would then loop through each of the strongly typed
TableAdapters and replace the TableAdapter’s connection string with
the new connection string with the user name.

It does not look like I can “foreach” my way through this. The only
way I can see to make this work right now is the hardcode a reference
to each TableAdapter by name and set its connection string.

Does anybody have any ideas for a better solution? I feel like I'm
missing something and over complicating this.

Thanks,
John

 

[Jesse Houwing]

Hello John Heitmuller.,

I’m using VisualStudio 2008. My original problem is that I need to
change the database user login name in my application connection
string at runtime. I have to maintain an audit able of user actions
on the database, so I need to know who is running the application.

My thought was in the form_load() I would read the application
ConenctionString. Replace the generic DB login name with the user’s
login name. I would then loop through each of the strongly typed
TableAdapters and replace the TableAdapter’s connection string with
the new connection string with the user name.

It does not look like I can “foreach†my way through this. The only
way I can see to make this work right now is the hardcode a reference
to each TableAdapter by name and set its connection string.

Does anybody have any ideas for a better solution? I feel like I'm
missing something and over complicating this.

The tableadapters can be configured to read the connectionstring from the
settings file. And you can change the settings file at runtime.

The best solution would probably be to use impersonation and use integrated
security to connect to the database. That way you know the username in the
DB without having to change anything to your app.

best alternative would be to pass the username in a parameter for each storedprocedure.

My last option would be to give every user their own connectionstring, this
defeats caching on a lot of levels, removes many of the advantages of connection
pooling and is generally a bad idea in itself. (Though trust me, I've been
there... I've even had to rewrite half of the ASP.NET membership providers
to get it to work, sometimes organizations are just too stubborn...