Do the TableAdapters have any limitations, gotcha's, or anything that
may bite ya in the rear down the road?
I'm looking for lessons learned and/or past experience. I'm starting
a new application and learning towards using the .NET 2.0 Strongly
Typed Dataset, TableAdapter, & partial classes for my DAL.
(For example, I was told performance was horrible, and from past
experience a company totally abandoned strongly typed datasets.
However, on further research it appears this was an issue with .NET
1.x but has been fixed in 2.0.)
-YinThe TableAdapters will cement you into a .NET 2.0 way of looking at things.
That is the major gotcha I can think of. You can avoid some of this by
abstracting the data access a bit. This will allow you to move to LINQ (or
something else) later without a complete rewrite.
Short answer: Don't embed everythign in your ASP.NET application and you
should be fine here.
STDs are a great way of looking at data, especially if you are going to head
to a more SOA type implementation. As they are already XML, they are easily
serialized. They are not the best for single entities, but you can translate
to business entities rather easily and even use the DataRows as a pseudo
business entity by wrapping the row.
STDs are also great for lazy loading and the TableAdapters can help
tremendously here.
Examine the tutorials on ASP.NET 2.0 on the MSDN site. There are some good
offerings on tiered development using .NET 2.0 features. Research a bit and
you can answer your own question, based on your applications.
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)
****************************************
********
Think outside the box!
****************************************
********
"Yin99" <ws@.ziowave.com> wrote in message
news:1182980286.876587.230920@.k29g2000hsd.googlegroups.com...
> Do the TableAdapters have any limitations, gotcha's, or anything that
> may bite ya in the rear down the road?
> I'm looking for lessons learned and/or past experience. I'm starting
> a new application and learning towards using the .NET 2.0 Strongly
> Typed Dataset, TableAdapter, & partial classes for my DAL.
> (For example, I was told performance was horrible, and from past
> experience a company totally abandoned strongly typed datasets.
> However, on further research it appears this was an issue with .NET
> 1.x but has been fixed in 2.0.)
> -Yin
>
Showing posts with label tableadapters. Show all posts
Showing posts with label tableadapters. Show all posts
Saturday, March 31, 2012
Wednesday, March 28, 2012
TableAdapters and db transactions (begin, comit,roleback....)
Hello
Doing some webapp. in ASP.NET and using som of tutorials from this site
http://www.asp.net/learn/dataaccess/default.aspx?tabid=63 . I havent seen
anything aboat transactions. Is it TableAdapters that runs the show ?
Or if not, where to implement it, becouse whan you to insert data you use a GridView or DetailsView
point to some methode yuo allready made in TableAdapter and thats it. Or am I missing somthing?
Thanks
Its Connection object which handles transactions for you.
SqlTransaction tran = Conn.BeginTransaction();
If you are using DataAdaptor, get the command object,
SqlCommand cmdDelete = DataAdaptor.GetDeleteCommand();
SqlCommand cmdInsert = DataAdaptor.GetInsertCommand();
SqlCommand cmdUpdate = DataAdaptor.GetUpdateCommand();
cmdDelete.Transaction = tran;
cmdInsert.Transaction = tran;
cmdUpdate.Transaction = tran;
Assign this tranaction object to a SQLCommand, use
tran.rollback, to rollbak transactions
tran.commit, to commit transactions
Hope this answers your question.
I think I've got it!!! :-)
ClientTableAdapter clientAdapt =newClientTableAdapter();
SqlConnection myConnection =newSqlConnection("server=(local)\\SQLExpress;Integrated Security=SSPI;database=Novabaza");SqlCommand myCommand =newSqlCommand();SqlTransaction myTrans;// Open the connection.
myConnection.Open();
// Assign the connection property.myCommand.Connection = myConnection;
// Begin the transaction.myTrans = myConnection.BeginTransaction();
// Assign transaction object for a pending local transactionmyCommand.Transaction = myTrans;
try{
// Create a SavepointclientAdapt.InsertClientdata(TextBoxName.Text, TextBoxSurname.Text,Convert.ToInt32(TextBoxTelnr.Text));myTrans.Commit();Response.Write(
" Records are written to the database!");}
catch (Exception ex)
{
myTrans.Rollback();
Response.Write("Record is not written to the database!");throw ex;
}
finally{
myConnection.Close();
}
InsertClientdata() is a query procedure I've made within (Client)tableadapter.
Now I'm goign to try something about using several adapters and creating some "SavePoints" for RollBack
Thanks a lot
TableAdapters and web.config
I have a class library that contains a number of TableAdapters and I'm using
this from a web application. Is there a way of getting the TableAdapters to
use the connectionstrings defined in web.config.
this from a web application. Is there a way of getting the TableAdapters to
use the connectionstrings defined in web.config.
From the MSDN documentation it seems like it's possible to override settings
with values in a config file for winform applications. Is the same possible
for web applications.
I have tried to add a connectionstring (under the connectionstring section)
in web.config with the same name as the name in the setting file. The
connectionstring in web.config points to a database that doesn't contain the
required schema. Since I'm not getting any errors and things are still
working, I assume it is still using the default connectionstring supplied at
designtime.Hi Kimbell,
Welcome to ASP.NET newsgroup.
Regarding on the configuration issue you mentioned when using TableAdapter
from class library in asp.net 2.0 project, I've also met this problem
before. Yes, as you has mentioned, when we has build the
DataSet/TableAdapter in class library project, the TableAdapter's
Connection /ConnectionString setting is persisted in the classlibrary
assembly's content so that when referenced in asp.net 2.0 project, it won't
use the web.config file's info (but still use the one persisted at
design-time in classlibrary project). Based on my research, as for the
Project Settings, the asp.net 2.0 seems has different support from winform
project. Currently one approach is manually modify the TableAdapter's
design-time generated code in the Classlibrary project. for example:
the TAbleAdapter's autogenerate code is as below, the "InitConnection"
function is just the one which supply connectionstring and constructing the
Connection instance for the TableAdapter
=============================
private void InitConnection()
{
this.m_connection = new System.Data.SqlClient.SqlConnection();
this.m_connection.ConnectionString =
DSLibrary.Properties.Settings.Default.NorthwindCon nectionString;
}
which retrieve the connection string through Project's Properties.Settings
collection. We can modify it to the following one:
======================
Object obj =
System.Configuration.ConfigurationSettings.GetConf ig("connectionStrings");
ConnectionStringsSection css = obj as ConnectionStringsSection;
string connstr =
css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
this.m_connection = new System.Data.SqlClient.SqlConnection();
this.m_connection.ConnectionString = connstr;
=====================
so that it will retrieve the info from the final hosting application's
application config file (appconfig or web.config).
Hope helps. Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
-------
| Thread-Topic: TableAdapters and web.config
| thread-index: AcXNckyfTDC6JTskQe231gX8p+7Y9A==
| X-WBNR-Posting-Host: 195.139.24.170
| From: "=?Utf-8?B?Q2hyaXN0b3BoZXIgS2ltYmVsbA==?="
<c_kimbell@.newsgroup.nospam>
| Subject: TableAdapters and web.config
| Date: Mon, 10 Oct 2005 01:12:04 -0700
| Lines: 15
| Message-ID: <69C48290-408C-4942-9F61-3C909A6766E3@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:349611
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| I have a class library that contains a number of TableAdapters and I'm
using
| this from a web application. Is there a way of getting the TableAdapters
to
| use the connectionstrings defined in web.config.
|
| From the MSDN documentation it seems like it's possible to override
settings
| with values in a config file for winform applications. Is the same
possible
| for web applications.
|
| I have tried to add a connectionstring (under the connectionstring
section)
| in web.config with the same name as the name in the setting file. The
| connectionstring in web.config points to a database that doesn't contain
the
| required schema. Since I'm not getting any errors and things are still
| working, I assume it is still using the default connectionstring supplied
at
| designtime.
|
|
So what you are recommending is to change the autogenerated code?
What about the following warning at the top of the file:
"Changes to this file may cause incorrect behavior and will be lost if the
code is regenerated."
Particularly the statement about lost changes.
I think a better approach is to change the ConnectionModifier to public in
the designer; then set the connectionstring from code.
I was hoping for a more elegant solution since Microsoft has put some work
into this settings system. Maybe in the next version.
"Steven Cheng[MSFT]" wrote:
> Hi Kimbell,
> Welcome to ASP.NET newsgroup.
> Regarding on the configuration issue you mentioned when using TableAdapter
> from class library in asp.net 2.0 project, I've also met this problem
> before. Yes, as you has mentioned, when we has build the
> DataSet/TableAdapter in class library project, the TableAdapter's
> Connection /ConnectionString setting is persisted in the classlibrary
> assembly's content so that when referenced in asp.net 2.0 project, it won't
> use the web.config file's info (but still use the one persisted at
> design-time in classlibrary project). Based on my research, as for the
> Project Settings, the asp.net 2.0 seems has different support from winform
> project. Currently one approach is manually modify the TableAdapter's
> design-time generated code in the Classlibrary project. for example:
> the TAbleAdapter's autogenerate code is as below, the "InitConnection"
> function is just the one which supply connectionstring and constructing the
> Connection instance for the TableAdapter
> =============================
> private void InitConnection()
> {
> this.m_connection = new System.Data.SqlClient.SqlConnection();
> this.m_connection.ConnectionString =
> DSLibrary.Properties.Settings.Default.NorthwindCon nectionString;
> }
> which retrieve the connection string through Project's Properties.Settings
> collection. We can modify it to the following one:
> ======================
> Object obj =
> System.Configuration.ConfigurationSettings.GetConf ig("connectionStrings");
> ConnectionStringsSection css = obj as ConnectionStringsSection;
> string connstr =
> css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
> this.m_connection = new System.Data.SqlClient.SqlConnection();
> this.m_connection.ConnectionString = connstr;
> =====================
> so that it will retrieve the info from the final hosting application's
> application config file (appconfig or web.config).
> Hope helps. Thanks,
> Steven Cheng
> Microsoft Online Support
Thanks for your response Kimbell,
Yes, the
========
"Changes to this file may cause incorrect behavior and will be lost if the
code is regenerated."
========
you mentioned is really a potential problem with my workaround. And your
appoarch on changing the ConnectionModifer to public is OK for
programmatical accessing. However, in most cases of ASP.NET 2.0 web
application, we will use design-time ObjectDataSource control to reference
the TableAdpater, and this is done through IDE interactively no code is
involved. So in such scenario, we may need to predefined the connection's
initilization in TableAdapter's code.
Anyway, I really appreciate your advice on the configuration setttings ,
and since this is a new feature involved in 2.0, I think it'll be improved
in the sequential versions so as to ease the component, class library
developing and seamless integrated into
front end applications.
Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
-------
| Thread-Topic: TableAdapters and web.config
| thread-index: AcXOO+CVs5sRlZYtRh+M2u+nQzNUBg==
| X-WBNR-Posting-Host: 195.139.24.170
| From: "=?Utf-8?B?Q2hyaXN0b3BoZXIgS2ltYmVsbA==?="
<c_kimbell@.newsgroup.nospam>
| References: <69C48290-408C-4942-9F61-3C909A6766E3@.microsoft.com>
<o4v8pDhzFHA.3712@.TK2MSFTNGXA02.phx.gbl>
| Subject: RE: TableAdapters and web.config
| Date: Tue, 11 Oct 2005 01:15:01 -0700
| Lines: 68
| Message-ID: <EAC2EB76-0E98-4837-AD33-55A57F82A6EA@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:349877
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| So what you are recommending is to change the autogenerated code?
| What about the following warning at the top of the file:
|
| "Changes to this file may cause incorrect behavior and will be lost if
the
| code is regenerated."
|
| Particularly the statement about lost changes.
|
| I think a better approach is to change the ConnectionModifier to public
in
| the designer; then set the connectionstring from code.
|
| I was hoping for a more elegant solution since Microsoft has put some
work
| into this settings system. Maybe in the next version.
|
|
| "Steven Cheng[MSFT]" wrote:
|
| > Hi Kimbell,
| >
| > Welcome to ASP.NET newsgroup.
| > Regarding on the configuration issue you mentioned when using
TableAdapter
| > from class library in asp.net 2.0 project, I've also met this problem
| > before. Yes, as you has mentioned, when we has build the
| > DataSet/TableAdapter in class library project, the TableAdapter's
| > Connection /ConnectionString setting is persisted in the classlibrary
| > assembly's content so that when referenced in asp.net 2.0 project, it
won't
| > use the web.config file's info (but still use the one persisted at
| > design-time in classlibrary project). Based on my research, as for the
| > Project Settings, the asp.net 2.0 seems has different support from
winform
| > project. Currently one approach is manually modify the TableAdapter's
| > design-time generated code in the Classlibrary project. for example:
| >
| > the TAbleAdapter's autogenerate code is as below, the "InitConnection"
| > function is just the one which supply connectionstring and constructing
the
| > Connection instance for the TableAdapter
| >
| > =============================
| > private void InitConnection()
| > {
| > this.m_connection = new System.Data.SqlClient.SqlConnection();
| > this.m_connection.ConnectionString =
| > DSLibrary.Properties.Settings.Default.NorthwindCon nectionString;
| > }
| >
| > which retrieve the connection string through Project's
Properties.Settings
| > collection. We can modify it to the following one:
| >
| > ======================
| >
| > Object obj =
| >
System.Configuration.ConfigurationSettings.GetConf ig("connectionStrings");
| > ConnectionStringsSection css = obj as ConnectionStringsSection;
| > string connstr =
| > css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
| > this.m_connection = new System.Data.SqlClient.SqlConnection();
| > this.m_connection.ConnectionString = connstr;
| >
| > =====================
| >
| > so that it will retrieve the info from the final hosting application's
| > application config file (appconfig or web.config).
| >
| > Hope helps. Thanks,
| >
| > Steven Cheng
| > Microsoft Online Support
| >
|
|
TableAdapters and true N-Tier
Unless someone has come up with a way, I still don't understand how you can
use TableAdapters in a true n-tier infrastructure... where the
DataAccessLayer is in one Dll and *only* the Datasets themselves can be
shared across layers.
I find it inconceivable that this suggestion
http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
(that's not me who suggested it) has been marked as "won't fix."
... even more strange that there hasn't been more of clamor about this in
the community. It seems that everybody nowadays either wasn't programming a
few years ago in VB.Classic days or has gotten amnesia and forgotten the
lessons learned in the past.
The TableAdapters are more robust than a regular DataAdapter. BUT, they're
USELESS if you can't place them outside of the DataSet *FILE* or dll as a
whole. I mean, they're placed in a separate namespace, they're not
intrinsically tied to the DataSet (i.e. they're not a nested class), and
placing them in the Dataset files violates TRUE n-tier rules.
-C. Moya
www.cmoya.comWell i can only say one thing regarding this
I agree ...
regards
Michel Posseth [MCP]
"CMM" <cmm@.nospam.com> schreef in bericht
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
> --
> -C. Moya
> www.cmoya.com
>
I don't like TableAdapters.
Forget n-tier, they have other problems too.
Here are my views on 'em -
http://groups.google.com/group/micr...b3192bc3?hl=en&
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.m...5/13/63199.aspx
----
"CMM" <cmm@.nospam.com> wrote in message
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
> --
> -C. Moya
> www.cmoya.com
>
"CMM" <cmm@.nospam.com> wrote in message
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
>
Why not just set the Table Adapters to "internal"? The DataAccessLayer
would be in one DLL and only the Datasets themselves would be shared.
Or why not go one better and not share the DataSet definitions at all.
Create an interface for each entity, and make the DataSet entities
(DataTables and DataRows) implement those interfaces. Then client code can
bind to the interfaces, and never have to know that it's reading and writing
to DataSets.
David
> Or why not go one better and not share the DataSet definitions at all.
> Create an interface for each entity, and make the DataSet entities
> (DataTables and DataRows) implement those interfaces. Then client code
> can bind to the interfaces, and never have to know that it's reading and
> writing to DataSets.
This is interesting... as I use interfaces already in a shared dll to
communicate with the DAL (i.e. the DAL dll doesn't get installed on the
client machine just to provide class definitions a la the lazy-man's
n-tier). But DataSets (and other "data-only" types and classes) get put into
the same shareable "Types" dll. I'll have to look into it... seems like an
aweful lot of work though to extend the "Interfaces" paradigm to Datasets as
well.
> Why not just set the Table Adapters to "internal"? The DataAccessLayer
> would be in one DLL and only the Datasets themselves would be shared.
I didn't know you could do that. You're saying you can *hide* the
TableAdapters? I'll look into it. But it still feels a bit icky.
-C. Moya
www.cmoya.com
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:%23LoOUTWZGHA.3448@.TK2MSFTNGP04.phx.gbl...
> "CMM" <cmm@.nospam.com> wrote in message
> news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Why not just set the Table Adapters to "internal"? The DataAccessLayer
> would be in one DLL and only the Datasets themselves would be shared.
> Or why not go one better and not share the DataSet definitions at all.
> Create an interface for each entity, and make the DataSet entities
> (DataTables and DataRows) implement those interfaces. Then client code
> can bind to the interfaces, and never have to know that it's reading and
> writing to DataSets.
>
> David
>
I expect that the MS folks are working on this aspect of TableAdapters.
Check out Jackie Goldstein's comments as well. He's been demonstrating how
to do this in his talks.
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"CMM" <cmm@.nospam.com> wrote in message
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
> --
> -C. Moya
> www.cmoya.com
>
I've said it many times... the CLR (and for the most part Framework too)
guys did an outstanding job on .NET 2.0. But the IDE and Editor/Designer
guys were asleep the whole time. It's like everything was written by a bunch
of amatuers straight out of college.
Wow... I just read your article. I didn't know about the queries ... but
now I see in the code behind the bunch of "& _ " used to build the queries.
Ridiculous. Just plain ridiculous.
-C. Moya
www.cmoya.com
"Sahil Malik [MVP C#]" <contactmethrumyblog@.nospam.com> wrote in message
news:%23XQSWQWZGHA.3524@.TK2MSFTNGP04.phx.gbl...
>I don't like TableAdapters.
> Forget n-tier, they have other problems too.
> Here are my views on 'em -
> http://groups.google.com/group/micr...b3192bc3?hl=en&
>
> - Sahil Malik [MVP]
> ADO.NET 2.0 book -
> http://codebetter.com/blogs/sahil.m...5/13/63199.aspx
> ----
--
>
> "CMM" <cmm@.nospam.com> wrote in message
> news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
>
For what, the next major release of VS or what? This should have been done
right in VS2005 to begin with.
-C. Moya
www.cmoya.com
"William (Bill) Vaughn" <billvaRemoveThis@.nwlink.com> wrote in message
news:u5F35hWZGHA.1204@.TK2MSFTNGP04.phx.gbl...
>I expect that the MS folks are working on this aspect of TableAdapters.
>Check out Jackie Goldstein's comments as well. He's been demonstrating how
>to do this in his talks.
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> INETA Speaker
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> __________________________________
> "CMM" <cmm@.nospam.com> wrote in message
> news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
>
use TableAdapters in a true n-tier infrastructure... where the
DataAccessLayer is in one Dll and *only* the Datasets themselves can be
shared across layers.
I find it inconceivable that this suggestion
http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
(that's not me who suggested it) has been marked as "won't fix."
... even more strange that there hasn't been more of clamor about this in
the community. It seems that everybody nowadays either wasn't programming a
few years ago in VB.Classic days or has gotten amnesia and forgotten the
lessons learned in the past.
The TableAdapters are more robust than a regular DataAdapter. BUT, they're
USELESS if you can't place them outside of the DataSet *FILE* or dll as a
whole. I mean, they're placed in a separate namespace, they're not
intrinsically tied to the DataSet (i.e. they're not a nested class), and
placing them in the Dataset files violates TRUE n-tier rules.
-C. Moya
www.cmoya.comWell i can only say one thing regarding this
I agree ...
regards
Michel Posseth [MCP]
"CMM" <cmm@.nospam.com> schreef in bericht
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
> --
> -C. Moya
> www.cmoya.com
>
I don't like TableAdapters.
Forget n-tier, they have other problems too.
Here are my views on 'em -
http://groups.google.com/group/micr...b3192bc3?hl=en&
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.m...5/13/63199.aspx
----
"CMM" <cmm@.nospam.com> wrote in message
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
> --
> -C. Moya
> www.cmoya.com
>
"CMM" <cmm@.nospam.com> wrote in message
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
>
Why not just set the Table Adapters to "internal"? The DataAccessLayer
would be in one DLL and only the Datasets themselves would be shared.
Or why not go one better and not share the DataSet definitions at all.
Create an interface for each entity, and make the DataSet entities
(DataTables and DataRows) implement those interfaces. Then client code can
bind to the interfaces, and never have to know that it's reading and writing
to DataSets.
David
> Or why not go one better and not share the DataSet definitions at all.
> Create an interface for each entity, and make the DataSet entities
> (DataTables and DataRows) implement those interfaces. Then client code
> can bind to the interfaces, and never have to know that it's reading and
> writing to DataSets.
This is interesting... as I use interfaces already in a shared dll to
communicate with the DAL (i.e. the DAL dll doesn't get installed on the
client machine just to provide class definitions a la the lazy-man's
n-tier). But DataSets (and other "data-only" types and classes) get put into
the same shareable "Types" dll. I'll have to look into it... seems like an
aweful lot of work though to extend the "Interfaces" paradigm to Datasets as
well.
> Why not just set the Table Adapters to "internal"? The DataAccessLayer
> would be in one DLL and only the Datasets themselves would be shared.
I didn't know you could do that. You're saying you can *hide* the
TableAdapters? I'll look into it. But it still feels a bit icky.
-C. Moya
www.cmoya.com
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:%23LoOUTWZGHA.3448@.TK2MSFTNGP04.phx.gbl...
> "CMM" <cmm@.nospam.com> wrote in message
> news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Why not just set the Table Adapters to "internal"? The DataAccessLayer
> would be in one DLL and only the Datasets themselves would be shared.
> Or why not go one better and not share the DataSet definitions at all.
> Create an interface for each entity, and make the DataSet entities
> (DataTables and DataRows) implement those interfaces. Then client code
> can bind to the interfaces, and never have to know that it's reading and
> writing to DataSets.
>
> David
>
I expect that the MS folks are working on this aspect of TableAdapters.
Check out Jackie Goldstein's comments as well. He's been demonstrating how
to do this in his talks.
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"CMM" <cmm@.nospam.com> wrote in message
news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
> Unless someone has come up with a way, I still don't understand how you
> can use TableAdapters in a true n-tier infrastructure... where the
> DataAccessLayer is in one Dll and *only* the Datasets themselves can be
> shared across layers.
> I find it inconceivable that this suggestion
> http://lab.msdn.microsoft.com/produ...9c-1a04d76036e4
> (that's not me who suggested it) has been marked as "won't fix."
> ... even more strange that there hasn't been more of clamor about this in
> the community. It seems that everybody nowadays either wasn't programming
> a few years ago in VB.Classic days or has gotten amnesia and forgotten the
> lessons learned in the past.
> The TableAdapters are more robust than a regular DataAdapter. BUT, they're
> USELESS if you can't place them outside of the DataSet *FILE* or dll as a
> whole. I mean, they're placed in a separate namespace, they're not
> intrinsically tied to the DataSet (i.e. they're not a nested class), and
> placing them in the Dataset files violates TRUE n-tier rules.
> --
> -C. Moya
> www.cmoya.com
>
I've said it many times... the CLR (and for the most part Framework too)
guys did an outstanding job on .NET 2.0. But the IDE and Editor/Designer
guys were asleep the whole time. It's like everything was written by a bunch
of amatuers straight out of college.
Wow... I just read your article. I didn't know about the queries ... but
now I see in the code behind the bunch of "& _ " used to build the queries.
Ridiculous. Just plain ridiculous.
-C. Moya
www.cmoya.com
"Sahil Malik [MVP C#]" <contactmethrumyblog@.nospam.com> wrote in message
news:%23XQSWQWZGHA.3524@.TK2MSFTNGP04.phx.gbl...
>I don't like TableAdapters.
> Forget n-tier, they have other problems too.
> Here are my views on 'em -
> http://groups.google.com/group/micr...b3192bc3?hl=en&
>
> - Sahil Malik [MVP]
> ADO.NET 2.0 book -
> http://codebetter.com/blogs/sahil.m...5/13/63199.aspx
> ----
--
>
> "CMM" <cmm@.nospam.com> wrote in message
> news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
>
For what, the next major release of VS or what? This should have been done
right in VS2005 to begin with.
-C. Moya
www.cmoya.com
"William (Bill) Vaughn" <billvaRemoveThis@.nwlink.com> wrote in message
news:u5F35hWZGHA.1204@.TK2MSFTNGP04.phx.gbl...
>I expect that the MS folks are working on this aspect of TableAdapters.
>Check out Jackie Goldstein's comments as well. He's been demonstrating how
>to do this in his talks.
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> INETA Speaker
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> __________________________________
> "CMM" <cmm@.nospam.com> wrote in message
> news:O5ZD6mVZGHA.1348@.TK2MSFTNGP05.phx.gbl...
>
TableAdapters Created in Dataset (XSD) Issues
Hi,
I've been trying to work with the XSDs and ran into a few road blocks.
1. Stored procedures that uses temp tables, i.e. #TempTable. The
wizard complains that #TempTable is an invalid object. What gives?
2. How do you programatically change the connection string at runtime
when using these TableAdapters via databinding in the IDE GUI?
Thanks,
Nick HustakNick,
Is the stored procedure creating the temp table itself, as opposed to
using a temp table that is created on the same connection by another
procedure?
Also, the connection string handling within 2005 for datasets (XSD) is
pretty weak in my opinion. If you're using the dataset within your
application, then it can use the application or web config file to
store the string. But if you're using a common dataset in a class
library then it uses the connection string from the sql server you have
registered in your IDE and stores it *programmatically* within the
settings designer code. It's because it is a class library and so will
use the configuration from the parent application.
The only way that I know of to override this is to change the
InitConnection method within the dataset designer code to use the
application config connection string from the parent application. This
works, but the obvious problem is that if you then need to change
anything with the adapter from the designer, it will overwrite this
code.
So I guess what you (and I) have to do is wait until right before the
application is to be deployed, and change the InitConnection methods to
use the configuration file settings. This, in my opinion, is not an
acceptable solution, but I'm not sure how else they could implement the
functionality.
Thanks,
Gary
On 27 Jun 2006 06:42:41 -0700, "Gary" <ggalehouse@.neo.rr.com> wrote:
>Nick,
>Is the stored procedure creating the temp table itself, as opposed to
>using a temp table that is created on the same connection by another
>procedure?
>Also, the connection string handling within 2005 for datasets (XSD) is
>pretty weak in my opinion. If you're using the dataset within your
>application, then it can use the application or web config file to
>store the string. But if you're using a common dataset in a class
>library then it uses the connection string from the sql server you have
>registered in your IDE and stores it *programmatically* within the
>settings designer code. It's because it is a class library and so will
>use the configuration from the parent application.
>The only way that I know of to override this is to change the
>InitConnection method within the dataset designer code to use the
>application config connection string from the parent application. This
>works, but the obvious problem is that if you then need to change
>anything with the adapter from the designer, it will overwrite this
>code.
>So I guess what you (and I) have to do is wait until right before the
>application is to be deployed, and change the InitConnection methods to
>use the configuration file settings. This, in my opinion, is not an
>acceptable solution, but I'm not sure how else they could implement the
>functionality.
>Thanks,
>Gary
Gary,
First, thanks for a well 'typed (spoken)' reply. My stored procs use
temp tables for intermediate calcs and things ala CREATE TABLE
#Temp...
I've since seen from another thread that MS KNOWS about this and did
nothing about it. It would appear you can still use the proc in a
dataset, but forget getting a schema in the IDE GUI - it won't read
it. Kind of silly IMHO.
And unfortunately you have confirmed my fear - they let this out the
door without serious consideration for how it works. Why in the world
they would not provide an easy way to override the connection strings
to datasets is beyond me. Wow they dropped the ball on the designer
- I'm a bit suprised seeing as they grabbed Anders from Delphi, which
has excellent designer support for databases work.
Oh well - thanks for the detailed explanation. I really am not happy
with having to remember to swap around the init string in the web
config. I toyed around with trying to manipulate it on the fly, but
it would seem it's completely locked out from programmatic
modification. That would have solved a lot of these issues.
I wonder if DLINQ is going to have the same silly issues. So
close..but these are damn near brick walls. I have zero urge to hand
code all my table objects - such a waste of time.
Thanks again,
Nick
I've been trying to work with the XSDs and ran into a few road blocks.
1. Stored procedures that uses temp tables, i.e. #TempTable. The
wizard complains that #TempTable is an invalid object. What gives?
2. How do you programatically change the connection string at runtime
when using these TableAdapters via databinding in the IDE GUI?
Thanks,
Nick HustakNick,
Is the stored procedure creating the temp table itself, as opposed to
using a temp table that is created on the same connection by another
procedure?
Also, the connection string handling within 2005 for datasets (XSD) is
pretty weak in my opinion. If you're using the dataset within your
application, then it can use the application or web config file to
store the string. But if you're using a common dataset in a class
library then it uses the connection string from the sql server you have
registered in your IDE and stores it *programmatically* within the
settings designer code. It's because it is a class library and so will
use the configuration from the parent application.
The only way that I know of to override this is to change the
InitConnection method within the dataset designer code to use the
application config connection string from the parent application. This
works, but the obvious problem is that if you then need to change
anything with the adapter from the designer, it will overwrite this
code.
So I guess what you (and I) have to do is wait until right before the
application is to be deployed, and change the InitConnection methods to
use the configuration file settings. This, in my opinion, is not an
acceptable solution, but I'm not sure how else they could implement the
functionality.
Thanks,
Gary
On 27 Jun 2006 06:42:41 -0700, "Gary" <ggalehouse@.neo.rr.com> wrote:
>Nick,
>Is the stored procedure creating the temp table itself, as opposed to
>using a temp table that is created on the same connection by another
>procedure?
>Also, the connection string handling within 2005 for datasets (XSD) is
>pretty weak in my opinion. If you're using the dataset within your
>application, then it can use the application or web config file to
>store the string. But if you're using a common dataset in a class
>library then it uses the connection string from the sql server you have
>registered in your IDE and stores it *programmatically* within the
>settings designer code. It's because it is a class library and so will
>use the configuration from the parent application.
>The only way that I know of to override this is to change the
>InitConnection method within the dataset designer code to use the
>application config connection string from the parent application. This
>works, but the obvious problem is that if you then need to change
>anything with the adapter from the designer, it will overwrite this
>code.
>So I guess what you (and I) have to do is wait until right before the
>application is to be deployed, and change the InitConnection methods to
>use the configuration file settings. This, in my opinion, is not an
>acceptable solution, but I'm not sure how else they could implement the
>functionality.
>Thanks,
>Gary
Gary,
First, thanks for a well 'typed (spoken)' reply. My stored procs use
temp tables for intermediate calcs and things ala CREATE TABLE
#Temp...
I've since seen from another thread that MS KNOWS about this and did
nothing about it. It would appear you can still use the proc in a
dataset, but forget getting a schema in the IDE GUI - it won't read
it. Kind of silly IMHO.
And unfortunately you have confirmed my fear - they let this out the
door without serious consideration for how it works. Why in the world
they would not provide an easy way to override the connection strings
to datasets is beyond me. Wow they dropped the ball on the designer
- I'm a bit suprised seeing as they grabbed Anders from Delphi, which
has excellent designer support for databases work.
Oh well - thanks for the detailed explanation. I really am not happy
with having to remember to swap around the init string in the web
config. I toyed around with trying to manipulate it on the fly, but
it would seem it's completely locked out from programmatic
modification. That would have solved a lot of these issues.
I wonder if DLINQ is going to have the same silly issues. So
close..but these are damn near brick walls. I have zero urge to hand
code all my table objects - such a waste of time.
Thanks again,
Nick
TableAdapters Created in Dataset (XSD) Issues
Hi,
I've been trying to work with the XSDs and ran into a few road blocks.
I've been trying to work with the XSDs and ran into a few road blocks.
1. Stored procedures that uses temp tables, i.e. #TempTable. The
wizard complains that #TempTable is an invalid object. What gives?
2. How do you programatically change the connection string at runtime
when using these TableAdapters via databinding in the IDE GUI?
Thanks,
Nick HustakNick,
Is the stored procedure creating the temp table itself, as opposed to
using a temp table that is created on the same connection by another
procedure?
Also, the connection string handling within 2005 for datasets (XSD) is
pretty weak in my opinion. If you're using the dataset within your
application, then it can use the application or web config file to
store the string. But if you're using a common dataset in a class
library then it uses the connection string from the sql server you have
registered in your IDE and stores it *programmatically* within the
settings designer code. It's because it is a class library and so will
use the configuration from the parent application.
The only way that I know of to override this is to change the
InitConnection method within the dataset designer code to use the
application config connection string from the parent application. This
works, but the obvious problem is that if you then need to change
anything with the adapter from the designer, it will overwrite this
code.
So I guess what you (and I) have to do is wait until right before the
application is to be deployed, and change the InitConnection methods to
use the configuration file settings. This, in my opinion, is not an
acceptable solution, but I'm not sure how else they could implement the
functionality.
Thanks,
Gary
On 27 Jun 2006 06:42:41 -0700, "Gary" <ggalehouse@.neo.rr.com> wrote:
>Nick,
>Is the stored procedure creating the temp table itself, as opposed to
>using a temp table that is created on the same connection by another
>procedure?
>Also, the connection string handling within 2005 for datasets (XSD) is
>pretty weak in my opinion. If you're using the dataset within your
>application, then it can use the application or web config file to
>store the string. But if you're using a common dataset in a class
>library then it uses the connection string from the sql server you have
>registered in your IDE and stores it *programmatically* within the
>settings designer code. It's because it is a class library and so will
>use the configuration from the parent application.
>The only way that I know of to override this is to change the
>InitConnection method within the dataset designer code to use the
>application config connection string from the parent application. This
>works, but the obvious problem is that if you then need to change
>anything with the adapter from the designer, it will overwrite this
>code.
>So I guess what you (and I) have to do is wait until right before the
>application is to be deployed, and change the InitConnection methods to
>use the configuration file settings. This, in my opinion, is not an
>acceptable solution, but I'm not sure how else they could implement the
>functionality.
>Thanks,
>Gary
Gary,
First, thanks for a well 'typed (spoken)' reply. My stored procs use
temp tables for intermediate calcs and things ala CREATE TABLE
#Temp...
I've since seen from another thread that MS KNOWS about this and did
nothing about it. It would appear you can still use the proc in a
dataset, but forget getting a schema in the IDE GUI - it won't read
it. Kind of silly IMHO.
And unfortunately you have confirmed my fear - they let this out the
door without serious consideration for how it works. Why in the world
they would not provide an easy way to override the connection strings
to datasets is beyond me. Wow they dropped the ball on the designer
- I'm a bit suprised seeing as they grabbed Anders from Delphi, which
has excellent designer support for databases work.
Oh well - thanks for the detailed explanation. I really am not happy
with having to remember to swap around the init string in the web
config. I toyed around with trying to manipulate it on the fly, but
it would seem it's completely locked out from programmatic
modification. That would have solved a lot of these issues.
I wonder if DLINQ is going to have the same silly issues. So
close..but these are damn near brick walls. I have zero urge to hand
code all my table objects - such a waste of time.
Thanks again,
Nick
TableAdapters and web.config
I have a class library that contains a number of TableAdapters and I'm using
this from a web application. Is there a way of getting the TableAdapters to
use the connectionstrings defined in web.config.
From the MSDN documentation it seems like it's possible to override settings
with values in a config file for winform applications. Is the same possible
for web applications.
I have tried to add a connectionstring (under the connectionstring section)
in web.config with the same name as the name in the setting file. The
connectionstring in web.config points to a database that doesn't contain the
required schema. Since I'm not getting any errors and things are still
working, I assume it is still using the default connectionstring supplied at
designtime.Hi Kimbell,
Welcome to ASP.NET newsgroup.
Regarding on the configuration issue you mentioned when using TableAdapter
from class library in asp.net 2.0 project, I've also met this problem
before. Yes, as you has mentioned, when we has build the
DataSet/TableAdapter in class library project, the TableAdapter's
Connection /ConnectionString setting is persisted in the classlibrary
assembly's content so that when referenced in asp.net 2.0 project, it won't
use the web.config file's info (but still use the one persisted at
design-time in classlibrary project). Based on my research, as for the
Project Settings, the asp.net 2.0 seems has different support from winform
project. Currently one approach is manually modify the TableAdapter's
design-time generated code in the Classlibrary project. for example:
the TAbleAdapter's autogenerate code is as below, the "InitConnection"
function is just the one which supply connectionstring and constructing the
Connection instance for the TableAdapter
=============================
private void InitConnection()
{
this.m_connection = new System.Data.SqlClient.SqlConnection();
this.m_connection.ConnectionString =
DSLibrary.Properties.Settings.Default.NorthwindConnectionString;
}
which retrieve the connection string through Project's Properties.Settings
collection. We can modify it to the following one:
======================
Object obj =
System.Configuration.ConfigurationSettings.GetConfig("connectionStrings");
ConnectionStringsSection css = obj as ConnectionStringsSection;
string connstr =
css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
this.m_connection = new System.Data.SqlClient.SqlConnection();
this.m_connection.ConnectionString = connstr;
=====================
so that it will retrieve the info from the final hosting application's
application config file (appconfig or web.config).
Hope helps. Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
| Thread-Topic: TableAdapters and web.config
| thread-index: AcXNckyfTDC6JTskQe231gX8p+7Y9A==
| X-WBNR-Posting-Host: 195.139.24.170
| From: "examnotes"
<c_kimbell@.newsgroup.nospam>
| Subject: TableAdapters and web.config
| Date: Mon, 10 Oct 2005 01:12:04 -0700
| Lines: 15
| Message-ID: <69C48290-408C-4942-9F61-3C909A6766E3@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:349611
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| I have a class library that contains a number of TableAdapters and I'm
using
| this from a web application. Is there a way of getting the TableAdapters
to
| use the connectionstrings defined in web.config.
|
| From the MSDN documentation it seems like it's possible to override
settings
| with values in a config file for winform applications. Is the same
possible
| for web applications.
|
| I have tried to add a connectionstring (under the connectionstring
section)
| in web.config with the same name as the name in the setting file. The
| connectionstring in web.config points to a database that doesn't contain
the
| required schema. Since I'm not getting any errors and things are still
| working, I assume it is still using the default connectionstring supplied
at
| designtime.
|
|
So what you are recommending is to change the autogenerated code?
What about the following warning at the top of the file:
"Changes to this file may cause incorrect behavior and will be lost if the
code is regenerated."
Particularly the statement about lost changes.
I think a better approach is to change the ConnectionModifier to public in
the designer; then set the connectionstring from code.
I was hoping for a more elegant solution since Microsoft has put some work
into this settings system. Maybe in the next version.
"Steven Cheng[MSFT]" wrote:
> Hi Kimbell,
> Welcome to ASP.NET newsgroup.
> Regarding on the configuration issue you mentioned when using TableAdapter
> from class library in asp.net 2.0 project, I've also met this problem
> before. Yes, as you has mentioned, when we has build the
> DataSet/TableAdapter in class library project, the TableAdapter's
> Connection /ConnectionString setting is persisted in the classlibrary
> assembly's content so that when referenced in asp.net 2.0 project, it won'
t
> use the web.config file's info (but still use the one persisted at
> design-time in classlibrary project). Based on my research, as for the
> Project Settings, the asp.net 2.0 seems has different support from winform
> project. Currently one approach is manually modify the TableAdapter's
> design-time generated code in the Classlibrary project. for example:
> the TAbleAdapter's autogenerate code is as below, the "InitConnection"
> function is just the one which supply connectionstring and constructing th
e
> Connection instance for the TableAdapter
> =============================
> private void InitConnection()
> {
> this.m_connection = new System.Data.SqlClient.SqlConnection();
> this.m_connection.ConnectionString =
> DSLibrary.Properties.Settings.Default.NorthwindConnectionString;
> }
> which retrieve the connection string through Project's Properties.Setting
s
> collection. We can modify it to the following one:
> ======================
> Object obj =
> System.Configuration.ConfigurationSettings.GetConfig("connectionStrings");
> ConnectionStringsSection css = obj as ConnectionStringsSection;
> string connstr =
> css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
> this.m_connection = new System.Data.SqlClient.SqlConnection();
> this.m_connection.ConnectionString = connstr;
> =====================
> so that it will retrieve the info from the final hosting application's
> application config file (appconfig or web.config).
> Hope helps. Thanks,
> Steven Cheng
> Microsoft Online Support
>
Thanks for your response Kimbell,
Yes, the
========
"Changes to this file may cause incorrect behavior and will be lost if the
code is regenerated."
========
you mentioned is really a potential problem with my workaround. And your
appoarch on changing the ConnectionModifer to public is OK for
programmatical accessing. However, in most cases of ASP.NET 2.0 web
application, we will use design-time ObjectDataSource control to reference
the TableAdpater, and this is done through IDE interactively no code is
involved. So in such scenario, we may need to predefined the connection's
initilization in TableAdapter's code.
Anyway, I really appreciate your advice on the configuration setttings ,
and since this is a new feature involved in 2.0, I think it'll be improved
in the sequential versions so as to ease the component, class library
developing and seamless integrated into
front end applications.
Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
--
| Thread-Topic: TableAdapters and web.config
| thread-index: AcXOO+CVs5sRlZYtRh+M2u+nQzNUBg==
| X-WBNR-Posting-Host: 195.139.24.170
| From: "examnotes"
<c_kimbell@.newsgroup.nospam>
| References: <69C48290-408C-4942-9F61-3C909A6766E3@.microsoft.com>
<o4v8pDhzFHA.3712@.TK2MSFTNGXA02.phx.gbl>
| Subject: RE: TableAdapters and web.config
| Date: Tue, 11 Oct 2005 01:15:01 -0700
| Lines: 68
| Message-ID: <EAC2EB76-0E98-4837-AD33-55A57F82A6EA@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:349877
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| So what you are recommending is to change the autogenerated code?
| What about the following warning at the top of the file:
|
| "Changes to this file may cause incorrect behavior and will be lost if
the
| code is regenerated."
|
| Particularly the statement about lost changes.
|
| I think a better approach is to change the ConnectionModifier to public
in
| the designer; then set the connectionstring from code.
|
| I was hoping for a more elegant solution since Microsoft has put some
work
| into this settings system. Maybe in the next version.
|
|
| "Steven Cheng[MSFT]" wrote:
|
| > Hi Kimbell,
| >
| > Welcome to ASP.NET newsgroup.
| > Regarding on the configuration issue you mentioned when using
TableAdapter
| > from class library in asp.net 2.0 project, I've also met this problem
| > before. Yes, as you has mentioned, when we has build the
| > DataSet/TableAdapter in class library project, the TableAdapter's
| > Connection /ConnectionString setting is persisted in the classlibrary
| > assembly's content so that when referenced in asp.net 2.0 project, it
won't
| > use the web.config file's info (but still use the one persisted at
| > design-time in classlibrary project). Based on my research, as for the
| > Project Settings, the asp.net 2.0 seems has different support from
winform
| > project. Currently one approach is manually modify the TableAdapter's
| > design-time generated code in the Classlibrary project. for example:
| >
| > the TAbleAdapter's autogenerate code is as below, the "InitConnection"
| > function is just the one which supply connectionstring and constructing
the
| > Connection instance for the TableAdapter
| >
| > =============================
| > private void InitConnection()
| > {
| > this.m_connection = new System.Data.SqlClient.SqlConnection();
| > this.m_connection.ConnectionString =
| > DSLibrary.Properties.Settings.Default.NorthwindConnectionString;
| > }
| >
| > which retrieve the connection string through Project's
Properties.Settings
| > collection. We can modify it to the following one:
| >
| > ======================
| >
| > Object obj =
| >
System.Configuration.ConfigurationSettings.GetConfig("connectionStrings");
| > ConnectionStringsSection css = obj as ConnectionStringsSection;
| > string connstr =
| > css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
| > this.m_connection = new System.Data.SqlClient.SqlConnection();
| > this.m_connection.ConnectionString = connstr;
| >
| > =====================
| >
| > so that it will retrieve the info from the final hosting application's
| > application config file (appconfig or web.config).
| >
| > Hope helps. Thanks,
| >
| > Steven Cheng
| > Microsoft Online Support
| >
|
|
this from a web application. Is there a way of getting the TableAdapters to
use the connectionstrings defined in web.config.
From the MSDN documentation it seems like it's possible to override settings
with values in a config file for winform applications. Is the same possible
for web applications.
I have tried to add a connectionstring (under the connectionstring section)
in web.config with the same name as the name in the setting file. The
connectionstring in web.config points to a database that doesn't contain the
required schema. Since I'm not getting any errors and things are still
working, I assume it is still using the default connectionstring supplied at
designtime.Hi Kimbell,
Welcome to ASP.NET newsgroup.
Regarding on the configuration issue you mentioned when using TableAdapter
from class library in asp.net 2.0 project, I've also met this problem
before. Yes, as you has mentioned, when we has build the
DataSet/TableAdapter in class library project, the TableAdapter's
Connection /ConnectionString setting is persisted in the classlibrary
assembly's content so that when referenced in asp.net 2.0 project, it won't
use the web.config file's info (but still use the one persisted at
design-time in classlibrary project). Based on my research, as for the
Project Settings, the asp.net 2.0 seems has different support from winform
project. Currently one approach is manually modify the TableAdapter's
design-time generated code in the Classlibrary project. for example:
the TAbleAdapter's autogenerate code is as below, the "InitConnection"
function is just the one which supply connectionstring and constructing the
Connection instance for the TableAdapter
=============================
private void InitConnection()
{
this.m_connection = new System.Data.SqlClient.SqlConnection();
this.m_connection.ConnectionString =
DSLibrary.Properties.Settings.Default.NorthwindConnectionString;
}
which retrieve the connection string through Project's Properties.Settings
collection. We can modify it to the following one:
======================
Object obj =
System.Configuration.ConfigurationSettings.GetConfig("connectionStrings");
ConnectionStringsSection css = obj as ConnectionStringsSection;
string connstr =
css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
this.m_connection = new System.Data.SqlClient.SqlConnection();
this.m_connection.ConnectionString = connstr;
=====================
so that it will retrieve the info from the final hosting application's
application config file (appconfig or web.config).
Hope helps. Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
| Thread-Topic: TableAdapters and web.config
| thread-index: AcXNckyfTDC6JTskQe231gX8p+7Y9A==
| X-WBNR-Posting-Host: 195.139.24.170
| From: "examnotes"
<c_kimbell@.newsgroup.nospam>
| Subject: TableAdapters and web.config
| Date: Mon, 10 Oct 2005 01:12:04 -0700
| Lines: 15
| Message-ID: <69C48290-408C-4942-9F61-3C909A6766E3@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:349611
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| I have a class library that contains a number of TableAdapters and I'm
using
| this from a web application. Is there a way of getting the TableAdapters
to
| use the connectionstrings defined in web.config.
|
| From the MSDN documentation it seems like it's possible to override
settings
| with values in a config file for winform applications. Is the same
possible
| for web applications.
|
| I have tried to add a connectionstring (under the connectionstring
section)
| in web.config with the same name as the name in the setting file. The
| connectionstring in web.config points to a database that doesn't contain
the
| required schema. Since I'm not getting any errors and things are still
| working, I assume it is still using the default connectionstring supplied
at
| designtime.
|
|
So what you are recommending is to change the autogenerated code?
What about the following warning at the top of the file:
"Changes to this file may cause incorrect behavior and will be lost if the
code is regenerated."
Particularly the statement about lost changes.
I think a better approach is to change the ConnectionModifier to public in
the designer; then set the connectionstring from code.
I was hoping for a more elegant solution since Microsoft has put some work
into this settings system. Maybe in the next version.
"Steven Cheng[MSFT]" wrote:
> Hi Kimbell,
> Welcome to ASP.NET newsgroup.
> Regarding on the configuration issue you mentioned when using TableAdapter
> from class library in asp.net 2.0 project, I've also met this problem
> before. Yes, as you has mentioned, when we has build the
> DataSet/TableAdapter in class library project, the TableAdapter's
> Connection /ConnectionString setting is persisted in the classlibrary
> assembly's content so that when referenced in asp.net 2.0 project, it won'
t
> use the web.config file's info (but still use the one persisted at
> design-time in classlibrary project). Based on my research, as for the
> Project Settings, the asp.net 2.0 seems has different support from winform
> project. Currently one approach is manually modify the TableAdapter's
> design-time generated code in the Classlibrary project. for example:
> the TAbleAdapter's autogenerate code is as below, the "InitConnection"
> function is just the one which supply connectionstring and constructing th
e
> Connection instance for the TableAdapter
> =============================
> private void InitConnection()
> {
> this.m_connection = new System.Data.SqlClient.SqlConnection();
> this.m_connection.ConnectionString =
> DSLibrary.Properties.Settings.Default.NorthwindConnectionString;
> }
> which retrieve the connection string through Project's Properties.Setting
s
> collection. We can modify it to the following one:
> ======================
> Object obj =
> System.Configuration.ConfigurationSettings.GetConfig("connectionStrings");
> ConnectionStringsSection css = obj as ConnectionStringsSection;
> string connstr =
> css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
> this.m_connection = new System.Data.SqlClient.SqlConnection();
> this.m_connection.ConnectionString = connstr;
> =====================
> so that it will retrieve the info from the final hosting application's
> application config file (appconfig or web.config).
> Hope helps. Thanks,
> Steven Cheng
> Microsoft Online Support
>
Thanks for your response Kimbell,
Yes, the
========
"Changes to this file may cause incorrect behavior and will be lost if the
code is regenerated."
========
you mentioned is really a potential problem with my workaround. And your
appoarch on changing the ConnectionModifer to public is OK for
programmatical accessing. However, in most cases of ASP.NET 2.0 web
application, we will use design-time ObjectDataSource control to reference
the TableAdpater, and this is done through IDE interactively no code is
involved. So in such scenario, we may need to predefined the connection's
initilization in TableAdapter's code.
Anyway, I really appreciate your advice on the configuration setttings ,
and since this is a new feature involved in 2.0, I think it'll be improved
in the sequential versions so as to ease the component, class library
developing and seamless integrated into
front end applications.
Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
--
| Thread-Topic: TableAdapters and web.config
| thread-index: AcXOO+CVs5sRlZYtRh+M2u+nQzNUBg==
| X-WBNR-Posting-Host: 195.139.24.170
| From: "examnotes"
<c_kimbell@.newsgroup.nospam>
| References: <69C48290-408C-4942-9F61-3C909A6766E3@.microsoft.com>
<o4v8pDhzFHA.3712@.TK2MSFTNGXA02.phx.gbl>
| Subject: RE: TableAdapters and web.config
| Date: Tue, 11 Oct 2005 01:15:01 -0700
| Lines: 68
| Message-ID: <EAC2EB76-0E98-4837-AD33-55A57F82A6EA@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:349877
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| So what you are recommending is to change the autogenerated code?
| What about the following warning at the top of the file:
|
| "Changes to this file may cause incorrect behavior and will be lost if
the
| code is regenerated."
|
| Particularly the statement about lost changes.
|
| I think a better approach is to change the ConnectionModifier to public
in
| the designer; then set the connectionstring from code.
|
| I was hoping for a more elegant solution since Microsoft has put some
work
| into this settings system. Maybe in the next version.
|
|
| "Steven Cheng[MSFT]" wrote:
|
| > Hi Kimbell,
| >
| > Welcome to ASP.NET newsgroup.
| > Regarding on the configuration issue you mentioned when using
TableAdapter
| > from class library in asp.net 2.0 project, I've also met this problem
| > before. Yes, as you has mentioned, when we has build the
| > DataSet/TableAdapter in class library project, the TableAdapter's
| > Connection /ConnectionString setting is persisted in the classlibrary
| > assembly's content so that when referenced in asp.net 2.0 project, it
won't
| > use the web.config file's info (but still use the one persisted at
| > design-time in classlibrary project). Based on my research, as for the
| > Project Settings, the asp.net 2.0 seems has different support from
winform
| > project. Currently one approach is manually modify the TableAdapter's
| > design-time generated code in the Classlibrary project. for example:
| >
| > the TAbleAdapter's autogenerate code is as below, the "InitConnection"
| > function is just the one which supply connectionstring and constructing
the
| > Connection instance for the TableAdapter
| >
| > =============================
| > private void InitConnection()
| > {
| > this.m_connection = new System.Data.SqlClient.SqlConnection();
| > this.m_connection.ConnectionString =
| > DSLibrary.Properties.Settings.Default.NorthwindConnectionString;
| > }
| >
| > which retrieve the connection string through Project's
Properties.Settings
| > collection. We can modify it to the following one:
| >
| > ======================
| >
| > Object obj =
| >
System.Configuration.ConfigurationSettings.GetConfig("connectionStrings");
| > ConnectionStringsSection css = obj as ConnectionStringsSection;
| > string connstr =
| > css.ConnectionStrings["LocalNorthwindConnStr"].ConnectionString;
| > this.m_connection = new System.Data.SqlClient.SqlConnection();
| > this.m_connection.ConnectionString = connstr;
| >
| > =====================
| >
| > so that it will retrieve the info from the final hosting application's
| > application config file (appconfig or web.config).
| >
| > Hope helps. Thanks,
| >
| > Steven Cheng
| > Microsoft Online Support
| >
|
|
TableAdapters using values
I have created a data access layer, have a datset with several tables. In VB I would like to access a the value of a particular cell, put that value into a variable. I am unsure how to do this. So far I have,
1Imports DataSet1TableAdapters2~~~~~~34Dim testID = Request("tid")56Dim levelAs Integer = 07Dim testsTableAdapterAs New TestsTableAdapter89level = testsTableAdapter.GetTestsByTestID(testID).Rows(0).Table.Columns(1)10 I know that this is incorrect, however I wish to get the value held in row 1 column 2. Any help would be much appreciated.
Hi,
Based on my understanding, you want to get the value held in particular cell by DataAdapter. If I have misunderstood you, please feel free to tell me, thanks.
Dim constrAs String =""'your connection stringDim connectionAs SqlConnection =New SqlConnection(constr)Dim sqlselAs String ="select * from test"Dim sdaAs SqlDataAdapter =New SqlDataAdapter(sqlsel, connection)Dim dsAs DataSet =New DataSet() sda.Fill(ds,"table")Dim levelAs Integer = ds.Tables("table").Rows(1)(2) Hope this can help you.
Try this
SqlConnection conn= new SqlConnection("YOUR CONNECTION STRING")
sql = "select * from TableName"
SqlDataAdapter ad = new SqlDataAdapter(sql, conn)
DataSet DS = new DataSet()
ad.Fill(DS,"TableName") // OR ad.Fill(DS.Tables(0))
Dim lvl As Integer
lvl = (int) DS.Table(0).Rows(1)
thanks for replying.
I was hoping to do it without setting a connection string or inputting SQL into the code. I want the dataset in my DAL to take care of this. Is there any way for the tableadapter to populate a new dataSet?
Please refer to this thread below
http://forums.asp.net/p/1187777/2031770.aspx#2031770
This might give you an idea
Subscribe to:
Posts (Atom)