* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download TableAdapters and TableAdapterManager
Survey
Document related concepts
Oracle Database wikipedia , lookup
Microsoft Access wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Ingres (database) wikipedia , lookup
Concurrency control wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Versant Object Database wikipedia , lookup
ContactPoint wikipedia , lookup
Relational model wikipedia , lookup
Transcript
ADO.Net TableAdapters and TableAdapterManager Code Camp 2008 Emmet Gray http://home.hot.rr.com/graye Introduction Strongly-typed DataSets Based upon DataSet and DataTable classes Wizard based (no need to hand code) Graphical view of the data Benefits Design-time type checking Intellisense Slight performance increase* Strongly-Typed DataSet Disadvantages Severe code bloat* Is often incorrectly used as a substitute for true n-tier “data access layer” Use of wizard may cause you to overlook other options such as stored procedures * Performance increases may be overshadowed by code bloat TableAdapter Strongly-typed version of the DataAdapter class The typical way to get data in/out of a strongly-typed DataSet One “DataAdapter” per table Has traditional Fill() and Update() methods Can be expanded with additional methods Concepts similar to that of stored procedures All queries located in one place TableAdapter Disadvantages Tied to the current data provider (i.e. SQL Server) To make a program database “agnostic” you would: Build the DataSet as usual Remove all TableAdapters Use the “Data Provider Factory” Schema Based All queries in a TableAdapter must return rows based upon the schema associated with the strongly-typed DataTable Joins are allows for filtering (but only columns in the base table are allowed) Exception for scalar queries (that return a single value) Supports parameterized queries Queries So how do I handle custom queries that return a different schema? Create a new TableAdapter! Also creates a new strongly-typed DataTable Update() methods Automatically creates the “CommandBuilder” equivalent Insert, Update, Delete commands Database Integrity Constraints upon the data Unique / Primary key Foreign Key Relationships Strongly-typed DataSets support relationships Enforces relationships at run-time Detects problems prior to saving to back-end database Saving the data TableAdapter.Update() method Scans the rows for changes and sends the changes to the back-end database How does the TableAdapter handle updates for queries based upon joins? Poorly… You’re are forced to write the update logic by hand Database Integrity Revisited Since strongly-typed DataSets support relationships, I’m good to go… right? That’s true for your locally cached version of the data But you must make sure you update the tables in the back-end database in the correct order! Particularly important in foreign-key relationship TableAdapterManager TableAdapterManager New to VS2008 Automatically scans the relationships and builds an UpdateAll() method that updates the tables in the correct order Not really based upon a “base class” Not tied to newer .Net Framework v3.x End Notes TableAdapter Based upon the associated schema of the strongly-typed DataTable Handy place to keep all your queries May not be suitable for all ocasions TableAdapterManager New component to solve the problem of updating the back-end database tables in the correct order