none
Generic Dataset to Typed Dataset Problem RRS feed

  • Question

  • Hi all

    I have a web application that allows a user to select, from a dropdown, the area to which they belong. They then can click a button to get information for that area from a database. A key thing to note here is that each area has and requires their own database (for reasons not relevant to this question).

    I currently have two DataSets.

    • dsArea1
    • dsArea2

    Each dataset is a mirror of the other insofar as the tables are exactly the same in design. 

    When the 'Go' button is clicked, I was hoping to:

    • Determine which area the person belongs - done
    • Have a generic dataset (Dataset ds;) - done
    • Cast the dataset to the type of the required dataset based on the user's selection - done
    • Have access to the tables within the typed dataset / intellisense - NOT WORKING

    My code states ds.tblOne and ds.tblTwo for example, which I want to keep given that the tables will always be the same in each dataset. Whilst I can simply remedy it by using ds.Tables["tblOne"].<property>, my curiosity is getting the better of me in whether this has to be the answer.

    Thanks in advance.

    Tuesday, January 30, 2018 10:37 AM

Answers

  • Well, Jon, to answer your question, let me give you some more focused reading material from my blog.

    I've written lots of blog posts about various aspects of the subject of DataAccess. I call the following links "The Works", because it delves into lots of elements relating to Data (after all, an application would be nothing without it's Data). From DataAccess to DataSets to DataBinding (all my DataBinding posts deal only with Windows Forms).
     
    First, let me say that DataAccess should never be included directly in the UI. See my blog post about Multi-tier applications:
     
    http://geek-goddess-bonnie.blogspot.com/2010/10/multi-tier-applications.html
     
    In the above blog post, I also have links to my 3-part DataAccess series, which I'll go ahead and include here also:
     
    May I suggest reading some of my blog posts about DataAccess, DataSets and Databinding ...
     
    First, check out my 3-part series on Data Access for some basic ideas. I'm using a SQL database, but the same would apply to other databases (except you'd use OleDb classes instead of Sql classes):
     
    http://geek-goddess-bonnie.blogspot.com/2009/09/dataaccess-part-i.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html
     
    Each post adds extra complexity to the Data Access classes, but more flexibility. The first post is enough to get you going in the right direction and give you a general idea of the concept, but the second post is more useful. The third post has a more complete example class, but it gets into using anonymous delegates and may be too much for a beginner (which, to be honest, I don't use the anonymous delegates anymore, but I used to on previous projects several years ago). However, even if you don't want to use the anonymous delegate approach, the more complete example class should show you how to save data, which the examples in the first two posts don't do.
     
    Those 3 posts are old, I wrote them back in 2009. They are still relevant, but I needed to add two things: implementing IDisposable and using TransactionScope for transactions. So, I added this post to my Data Access series:
     
    http://geek-goddess-bonnie.blogspot.com/2015/06/dataaccess-revisiting-yet-again.html
     
    Several of my readers have gotten back to me with some questions about this code and I realized that I'm still missing a few important items, such as DataAdapter.TableMappings!! So, I finally wrote a new post about that:
     
    http://geek-goddess-bonnie.blogspot.com/2016/08/more-dataaccess-and-you-thought-i-was.html
     
    One more post should be mentioned when talking about DataAccess, and that is the use of Stored Procedures. This is my most recent post and besides showing you a sample Stored Proc (for inserting or updating, both in the same Proc), I also show you how to call it (within my DataAccess class "framework") and a bonus: the code to automatically generate "CREATE PROCEDURE" SQL code which you can use to include in your own database utility application (or a start on writing such a utility if you don't have one).

    https://geek-goddess-bonnie.blogspot.com/2018/01/use-and-generate-put-stored-procedures.html

    I always use Typed DataSets and do *not* use TableAdapters ... so, here's a post I have about creating Typed DataSets without TableAdapters being generated.I know that DataSets have gotten a "bum rap" lately since lots of people prefer using Entity Framework, LINQ to SQL and similar types of ORMs. But I find Typed DataSets to be quite simple to use (especially when you avoid the TableAdapters):
     
    http://geek-goddess-bonnie.blogspot.com/2010/04/create-xsd.html
     
    Speaking of my dislike for TableAdapters, part of the reason is because, early on when they were first introduced, all the generated code "lived" in the same project (and even in the same generated files!). This doesn't bode well for separation of concerns, because you couldn't separate your Typed DataSet (basically a business/data entity) from the DataAccess tier!  A big no-no!  But, if you insist on using them, here is an MSDN article about how to separate your DataSets from their TableAdapters (putting them in different projects):
     
    https://msdn.microsoft.com/en-us/library/bb384586(v=vs.140).aspx
     
    You'll also want to be aware of this little "gotcha" that sometimes happens with the MSDataSetGenerator:
     
    http://geek-goddess-bonnie.blogspot.com/2012/08/msdatasetgenerator-gone-wild.html
     
    And lastly, a few posts about Databinding (these two searches have a few overlapping posts):
     
    https://geek-goddess-bonnie.blogspot.com/search?q=BindingSource
    https://geek-goddess-bonnie.blogspot.com/search?q=databind
     
    I hope these help and give you some ideas.


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    • Marked as answer by reyreyreyes Thursday, February 1, 2018 3:50 PM
    Thursday, February 1, 2018 3:11 PM

All replies

  • Hi reyreyreyes,

    >>Have access to the tables within the typed dataset / intellisense - NOT WORKING

    Could you please describe it in detailed with a bit more information, such as related code. it will be beneficial to resolve the issue.

    Best regards,

    Zhanglong


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, January 31, 2018 2:11 AM
    Moderator
  • Hi Jon,

    Why bother with two Typed DataSets if the database schema is the same? Won't the two Typed DataSets have the exact same .xsd data? If not, why not ... because it seems to me, from the way that you described it, that one Typed DataSet can serve the purpose for both of your "areas". Unless there are actually some difference between the "areas"?


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    Wednesday, January 31, 2018 6:05 AM
  • Hi Zhanglong

    Thank you for replying.

    Take this example:

                            DataSet dsGeneric = new DataSet(); // Untyped
                            dataset1 ds1 = new dataset1(); // Typed
                            dataset2 ds2 = new dataset2(); // Typed
    
                            if ("this text" == "this text")
                                dsGeneric = ds1;
                            else
                                dsGeneric = ds2;
    
                            Debug.Print(dsGeneric.tblContent.Rows.Count);

    VS will show a red squiggly line under 'tblContent', which is the table that appears in both of the typed datasets (which have exactly the same schema). 

    I know I could simply amend it to: dsGeneric.Tables["tblContent"].Rows.Count - but I'd like to know if there's a way harnessing the benefits of a strongly typed DataSet even in my situation.

    Wednesday, January 31, 2018 9:42 AM
  • Hi Bonnie

    Fancy seeing you here!

    The point of the different DataSets is to be able to allow different areas to have their own database, whilst keeping exactly the same format using database scripts that their respective person-in-charge (not a developer, only basic knowledge) can easily run. The schema has to be the same due to how they will update their own databases using an admin tool that will target the specific database they created. Using the selection of where they are, the program should then know how to contact that database (the database type could even differ: there may be SQL in one, and Oracle in another (alternative scripts will naturally be provided!)). 

    I'm as curious about whether you can even do this as the correct answer now! 

    Wednesday, January 31, 2018 9:49 AM
  • Hi Jon,

    The thing is that Typed DataSets *do not need* to know anything about where their data is coming from. If you're using TableAdapters, then that may not be the case, and I'm not sure if separating the TableAdapters from Typed DataSets alleviates that problem (because, frankly, I never use TableAdapters). In my opinion (don't know if you've read it on my blog or not), DataSets (Typed or not) are simply DTOs (Data Transfer Objects) and nothing more. They should not be "coupled" with the database. If you do it that way (don't use TableAdapters), then the same Typed DataSet can be filled from any database at all.

    So, I guess my first question to you is: are you using TableAdapters?


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    Wednesday, January 31, 2018 2:47 PM
  • Hi Bonnie

    I just loaded your blog, which I shall have another read of.

    What you state makes perfect sense. I see why there's no real reason to generate multiple DataSets with the same schema. I suppose I've been lured in by Microsoft's offering of TableAdapters at the point where I create my DataSet.

    So, the short answer is yes, I am using TableAdapters. Is the alternative to generate a custom class with SqlDataAdapters etc.? Or, should I be adding to the partial class that exists from my [new] generic DataSet that replaces separate ones?

    Thursday, February 1, 2018 11:25 AM
  • Well, Jon, to answer your question, let me give you some more focused reading material from my blog.

    I've written lots of blog posts about various aspects of the subject of DataAccess. I call the following links "The Works", because it delves into lots of elements relating to Data (after all, an application would be nothing without it's Data). From DataAccess to DataSets to DataBinding (all my DataBinding posts deal only with Windows Forms).
     
    First, let me say that DataAccess should never be included directly in the UI. See my blog post about Multi-tier applications:
     
    http://geek-goddess-bonnie.blogspot.com/2010/10/multi-tier-applications.html
     
    In the above blog post, I also have links to my 3-part DataAccess series, which I'll go ahead and include here also:
     
    May I suggest reading some of my blog posts about DataAccess, DataSets and Databinding ...
     
    First, check out my 3-part series on Data Access for some basic ideas. I'm using a SQL database, but the same would apply to other databases (except you'd use OleDb classes instead of Sql classes):
     
    http://geek-goddess-bonnie.blogspot.com/2009/09/dataaccess-part-i.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html
     
    Each post adds extra complexity to the Data Access classes, but more flexibility. The first post is enough to get you going in the right direction and give you a general idea of the concept, but the second post is more useful. The third post has a more complete example class, but it gets into using anonymous delegates and may be too much for a beginner (which, to be honest, I don't use the anonymous delegates anymore, but I used to on previous projects several years ago). However, even if you don't want to use the anonymous delegate approach, the more complete example class should show you how to save data, which the examples in the first two posts don't do.
     
    Those 3 posts are old, I wrote them back in 2009. They are still relevant, but I needed to add two things: implementing IDisposable and using TransactionScope for transactions. So, I added this post to my Data Access series:
     
    http://geek-goddess-bonnie.blogspot.com/2015/06/dataaccess-revisiting-yet-again.html
     
    Several of my readers have gotten back to me with some questions about this code and I realized that I'm still missing a few important items, such as DataAdapter.TableMappings!! So, I finally wrote a new post about that:
     
    http://geek-goddess-bonnie.blogspot.com/2016/08/more-dataaccess-and-you-thought-i-was.html
     
    One more post should be mentioned when talking about DataAccess, and that is the use of Stored Procedures. This is my most recent post and besides showing you a sample Stored Proc (for inserting or updating, both in the same Proc), I also show you how to call it (within my DataAccess class "framework") and a bonus: the code to automatically generate "CREATE PROCEDURE" SQL code which you can use to include in your own database utility application (or a start on writing such a utility if you don't have one).

    https://geek-goddess-bonnie.blogspot.com/2018/01/use-and-generate-put-stored-procedures.html

    I always use Typed DataSets and do *not* use TableAdapters ... so, here's a post I have about creating Typed DataSets without TableAdapters being generated.I know that DataSets have gotten a "bum rap" lately since lots of people prefer using Entity Framework, LINQ to SQL and similar types of ORMs. But I find Typed DataSets to be quite simple to use (especially when you avoid the TableAdapters):
     
    http://geek-goddess-bonnie.blogspot.com/2010/04/create-xsd.html
     
    Speaking of my dislike for TableAdapters, part of the reason is because, early on when they were first introduced, all the generated code "lived" in the same project (and even in the same generated files!). This doesn't bode well for separation of concerns, because you couldn't separate your Typed DataSet (basically a business/data entity) from the DataAccess tier!  A big no-no!  But, if you insist on using them, here is an MSDN article about how to separate your DataSets from their TableAdapters (putting them in different projects):
     
    https://msdn.microsoft.com/en-us/library/bb384586(v=vs.140).aspx
     
    You'll also want to be aware of this little "gotcha" that sometimes happens with the MSDataSetGenerator:
     
    http://geek-goddess-bonnie.blogspot.com/2012/08/msdatasetgenerator-gone-wild.html
     
    And lastly, a few posts about Databinding (these two searches have a few overlapping posts):
     
    https://geek-goddess-bonnie.blogspot.com/search?q=BindingSource
    https://geek-goddess-bonnie.blogspot.com/search?q=databind
     
    I hope these help and give you some ideas.


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    Thursday, February 1, 2018 3:10 PM
  • Well, Jon, to answer your question, let me give you some more focused reading material from my blog.

    I've written lots of blog posts about various aspects of the subject of DataAccess. I call the following links "The Works", because it delves into lots of elements relating to Data (after all, an application would be nothing without it's Data). From DataAccess to DataSets to DataBinding (all my DataBinding posts deal only with Windows Forms).
     
    First, let me say that DataAccess should never be included directly in the UI. See my blog post about Multi-tier applications:
     
    http://geek-goddess-bonnie.blogspot.com/2010/10/multi-tier-applications.html
     
    In the above blog post, I also have links to my 3-part DataAccess series, which I'll go ahead and include here also:
     
    May I suggest reading some of my blog posts about DataAccess, DataSets and Databinding ...
     
    First, check out my 3-part series on Data Access for some basic ideas. I'm using a SQL database, but the same would apply to other databases (except you'd use OleDb classes instead of Sql classes):
     
    http://geek-goddess-bonnie.blogspot.com/2009/09/dataaccess-part-i.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html
     
    Each post adds extra complexity to the Data Access classes, but more flexibility. The first post is enough to get you going in the right direction and give you a general idea of the concept, but the second post is more useful. The third post has a more complete example class, but it gets into using anonymous delegates and may be too much for a beginner (which, to be honest, I don't use the anonymous delegates anymore, but I used to on previous projects several years ago). However, even if you don't want to use the anonymous delegate approach, the more complete example class should show you how to save data, which the examples in the first two posts don't do.
     
    Those 3 posts are old, I wrote them back in 2009. They are still relevant, but I needed to add two things: implementing IDisposable and using TransactionScope for transactions. So, I added this post to my Data Access series:
     
    http://geek-goddess-bonnie.blogspot.com/2015/06/dataaccess-revisiting-yet-again.html
     
    Several of my readers have gotten back to me with some questions about this code and I realized that I'm still missing a few important items, such as DataAdapter.TableMappings!! So, I finally wrote a new post about that:
     
    http://geek-goddess-bonnie.blogspot.com/2016/08/more-dataaccess-and-you-thought-i-was.html
     
    One more post should be mentioned when talking about DataAccess, and that is the use of Stored Procedures. This is my most recent post and besides showing you a sample Stored Proc (for inserting or updating, both in the same Proc), I also show you how to call it (within my DataAccess class "framework") and a bonus: the code to automatically generate "CREATE PROCEDURE" SQL code which you can use to include in your own database utility application (or a start on writing such a utility if you don't have one).

    https://geek-goddess-bonnie.blogspot.com/2018/01/use-and-generate-put-stored-procedures.html

    I always use Typed DataSets and do *not* use TableAdapters ... so, here's a post I have about creating Typed DataSets without TableAdapters being generated.I know that DataSets have gotten a "bum rap" lately since lots of people prefer using Entity Framework, LINQ to SQL and similar types of ORMs. But I find Typed DataSets to be quite simple to use (especially when you avoid the TableAdapters):
     
    http://geek-goddess-bonnie.blogspot.com/2010/04/create-xsd.html
     
    Speaking of my dislike for TableAdapters, part of the reason is because, early on when they were first introduced, all the generated code "lived" in the same project (and even in the same generated files!). This doesn't bode well for separation of concerns, because you couldn't separate your Typed DataSet (basically a business/data entity) from the DataAccess tier!  A big no-no!  But, if you insist on using them, here is an MSDN article about how to separate your DataSets from their TableAdapters (putting them in different projects):
     
    https://msdn.microsoft.com/en-us/library/bb384586(v=vs.140).aspx
     
    You'll also want to be aware of this little "gotcha" that sometimes happens with the MSDataSetGenerator:
     
    http://geek-goddess-bonnie.blogspot.com/2012/08/msdatasetgenerator-gone-wild.html
     
    And lastly, a few posts about Databinding (these two searches have a few overlapping posts):
     
    https://geek-goddess-bonnie.blogspot.com/search?q=BindingSource
    https://geek-goddess-bonnie.blogspot.com/search?q=databind
     
    I hope these help and give you some ideas.


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    • Marked as answer by reyreyreyes Thursday, February 1, 2018 3:50 PM
    Thursday, February 1, 2018 3:11 PM
  • I got more than I bargained for in that post!

    Thanks Bonnie. I did read part 1 and 2 of your data access blogs earlier on today, and I'll take a look at those others as well. I'm very intrigued on the DataSet 'gotcha', so that's at the top of the to-read list!

    My application has been built as N-Tier as it happens! And, since my last post, I've been playing with using a simple DataSet without the generated adapters (though the way I made it 'without' is by deleting them afterwards, which I expect to find out is not the actual way to achieve that solution). I've since written the basic 'Get' methods, which is so much easier than the approach I had to take. It was within one of your blogs where you have a (not a quote: DB access base class) that simply holds your connection that I thought "of course!". Now, I can use the area selection to simply choose a different connection one way or the other, whilst still keep everything working as it should in its own tier. Also, I don't need multiple duplicate queries because the only thing that will change (for those on SQL Server) is the connection string. 

    As for data binding, I've got that going nicely too, though I have a feeling that's a subject that has far more scope than people maybe expect, and so I shall read up further on that too.

    Awesome help Bonnie, once again. Thank you.

    I'll mark this as an answer as, based on my reading already, you have directed me on to the write path.

    Thursday, February 1, 2018 3:50 PM
  • You're welcome, Jon! I'm glad I could help.

    That list, "The Works", is actually something I keep in a Note that I can just paste, all of or part of, into a reply on these Forums. I have updated it as needed over the years (as you may have noticed, the most recent blog link is from something I posted just 2 days ago).

    Anyway, good luck and have fun!  =0)


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    Thursday, February 1, 2018 4:25 PM