Connection and Transaction properties exposed as Friend on TableAdapters

modify created connection string | keyongtech

modify created connection string | keyongtech — Thu, 22 Jan 2009 05:47:58 GMT

PingBack from http://www.keyongtech.com/445951-modify-created-connection-string

The Visual Basic Team : Connection and Transaction properties exposed … at Restaurants

Mon, 31 Dec 2007 10:39:19 GMT

PingBack from http://restaurants.247blogging.info/?p=622

Connection Management with TableAdapters in .NET 2.0/Visual Studio 2005 « Rich Newman

Sat, 24 Mar 2007 15:44:53 GMT

PingBack from http://richnewman.wordpress.com/2007/03/04/connection-management-with-tableadapters-in-net-20visual-studio-2005/

re: Data Design Time Changes Beta1 to Beta2

The Visual Basic Team — Fri, 28 Jan 2005 19:55:00 GMT

ADO.NET 2.0 Comings and goings

Jackie Goldstein's Weblog — Sun, 15 Aug 2004 14:13:00 GMT

ADO.NET 2.0 Coming and goings

Jackie Goldstein's Weblog — Sun, 15 Aug 2004 14:06:00 GMT

re: Connection and Transaction properties exposed as Friend on TableAdapters

Steve Lasker — Fri, 13 Aug 2004 23:43:00 GMT

Ok, so how about this:
We expose a ConnectionModifier property on the DataSet designer that defaults to Protected, but developers can easily change to Friend or Public.
The issue is we've heard clearly that we should expose sensitive data, such as the Connection info, or the Command Collections outside the assembly. Our believe is connection strings would be well managed through the Settings class. If you change the Settings.YourConnectionString, the TableAdapters would utilize this value. However, I do recognize that developers do have well designed patterns that delegate the creation of a Connection to another library. ...so the property.
Creating a partial class for each TableAdapter would be PITA, and oh, by the way, we did likely steal the name you'd use Connection, so is it reasonable to default to Protected and you can simply toggle this in the Designer. Please don't ask for a Tools-Options to change the default :) This would be a simple thing to add at this point, and we're still hearing "ship it already".

BTW, still haven't had a chance to finish the Transaction sample, but I do have some of it done...
Steve

re: Connection and Transaction properties exposed as Friend on TableAdapters

Brian Noyes — Fri, 13 Aug 2004 23:28:00 GMT

I have to agree with Jeff. Our standard model for data access layers uses Enterprise Services, and the connection is managed from a base class that sits in a different assembly. The rest of the Table Adapter model will fit nicely into the way we do things, but the Connection not being accessible outside the assembly was already a pain, now you are making it less accessible. Having to add code to support this for every table adapter is going to cause a lot of pain. A data access layer does not know enough about the context in which it is going to be used to assume full responsibility for connection management, so the Connection of all things should be a settable property on the Table Adapter from outside the assembly.

re: Connection and Transaction properties exposed as Friend on TableAdapters

Jeff Davis — Wed, 11 Aug 2004 16:14:00 GMT

This seems like a major step backwards. Having to do this for every table adapter in our system will be onerous (we have more than 200 tables). The current design seems oriented towards casual, amateur developers rather than enterprise-class developers.

I strongly urge MS to reconsider this approach. If the properties are causing you problems, why not just code-gen extra methods that take the existing params plus a connection object and transaction object (tran object only on update methods)?

Why are the Data Components no longer on the Toolbox?

The Visual Basic Team — Thu, 05 Aug 2004 21:25:00 GMT