Re: Warning! Serious design flaw dataset / table adapter designer
- From: "William \(Bill\) Vaughn" <billvaRemoveThis@xxxxxxxxxx>
- Date: Tue, 5 Dec 2006 10:37:27 -0800
I'm going to let MS comment on this...
--
____________________________________
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.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------
"Jim Rand" <jimrand@xxxxxxxxxxxxx> wrote in message
news:OfDkDgJGHHA.1216@xxxxxxxxxxxxxxxxxxxxxxx
VS 2005 provides for dragging tables from a server connection to the
dataset designer creating both data tables and related table adapters.
For the most part, the relationships between tables are automatically
discovered and rendered on the designer surface.
For my application, it is necessary to change each SELECT, UPDATE, INSERT
and DELETE statement to customize the handling of timestamps (TS -->
CAST(TS AS INT) AS TS), concurrency conflict handling and retrieving the
autoincrement keys. OK - that's fine but somewhat painful (i.e., labor
intensive [12 tables * 4 sql statements]).
Switching from SQL Server 2000 to SQL Server 2005, you go from a table
owner to schema name metaphor. For example, dbo.OfficeType becomes
AgentNET.OfficeType where dbo is the owner (in 2000) and AgentNET is the
schema (in 2005).
Making the change in the designer should be relatively simple by changing
the underlying SQL statements as in:
SELECT OfficeTypeID, OfficeType, Description, ListOrder, CAST(TS AS INT)
AS TS FROM dbo.OfficeType
SELECT OfficeTypeID, OfficeType, Description, ListOrder, CAST(TS AS INT)
AS TS FROM AgencyNET.OfficeType
However, the designer appears to have screwed up the relationships between
tables preventing the application from working. The only fix was to delete
the xsd file and start over from scratch!
The dataset is a disconnected container for holding a subset of the data
on the desktop. The table adapter is not part of the dataset - it is a
wrapper to the data adapter that handles CRUD (create, read, update,
delete) operations. Combining both dataset and adapters clouds the
distinction. Using the designer, changing where the data comes from breaks
the container.
For my development, I'm going back to having one container (xsd) for the
dataset with no table adapters and a separate container for the data
adapters. That way, the backend can be changed without breaking the rest
of the application. So much for dragging tables to designer surface ever
again.
This was definitely one of those "You've got to be **#&$*#@ me!" moments
in life.
PS to Microsoft: Did you really try this stuff out prior to shipping?
.
- References:
- Prev by Date: Re: How to determinate the data type
- Next by Date: Re: Missing a digit
- Previous by thread: Warning! Serious design flaw dataset / table adapter designer
- Next by thread: Re: Warning! Serious design flaw dataset / table adapter designer
- Index(es):
Relevant Pages
|
