Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Visual Studio.NET / Extensibility / July 2006

Tip: Looking for answers? Try searching our database.

Possible DDEX bug?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Robert Simpson - 11 Apr 2006 18:20 GMT
I am editing the UpdateCommand of a typed dataset's tableadapter, and
noticing that the parameter dbtypes keep changing on me.  I've isolated the
problem down to these repeatable steps that occur even in Sql Server 2005
Express Edition:

1.  Create a new C# Windows Application
2.  Right-click the project and select "Add->New Item"
3.  Select "DataSet" and add it.  DataSet1.xsd should be in the project now
and should be open.
4.  In the VS Server Explorer, create a new Sql Server Express database
file.
5.  Create a new table in the newly-created database with the following
definition:
   CREATE TABLE FOO (Id bigint primary key, myfloat float)

6.  Expand the tables list for the new database you've made.
7.  Drag and drop the FOO table onto the typed dataset designer you added in
step 3.
8.  Right-click the typed dataset and select "Configure"
9.  Click the "Advanced Options" button, and turn off "Use optimistic
concurrency" and "Refresh the datatable".  Click OK afterwards.  This is
done strictly to simplify the steps that follow and reduce the number of
parameters in the update query.

10. Hit the "Finish" button.
11. Right-click the FOOTableAdapter and select "Properties"
12. Go to the UpdateCommand in the properties for FooTableAdapter and expand
it.
13. Examine the Parameters property, and ensure that the "myfloat" parameter
has a DbType of "Double".  Click OK or Cancel.
14. Press the "..." on the CommandText for the UpdateCommand to bring up the
Query Builder.
15. Do nothing in the Query Builder.  Press the OK button.
16. Examine the Parameters property for the UpdateCommand.  You will see
that the "myfloat" column now has a DbType of "Single".

This problem is much worse in my SQLite provider.  Int64's get changed to
Int32's, double's turn into decimal's, etc.  Re-configuring the typed
dataset (just right-click, hit Configure, and then Finish) will fix it back
to normal.  The Query Builder seems to be using some odd code path to
reconstruct these parameter types.

Robert Simpson
Programmer at Large
"Gary Chang[MSFT]" - 12 Apr 2006 08:27 GMT
Hi Robert,

>I am editing the UpdateCommand of a typed dataset's
>tableadapter, and noticing that the parameter dbtypes
>keep changing on me.  I've isolated the problem down to
>these repeatable steps that occur even in Sql Server 2005
>Express Edition:
>...

This newsgroup focuses on the issue about customization, extension, and
integration with Visual Studio, including macros, add-ins, and the VS SDK.
However your problem is a VS2005 typed dataset's tableadapter issue, if you
asked it in a more appropriate newsgroup, you'd get better and quicker help
there:

microsoft.public.dotnet.framework.adonet

Thanks for your understanding.

Best regards,

Gary Chang
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Robert Simpson - 12 Apr 2006 15:46 GMT
> Hi Robert,
>
[quoted text clipped - 16 lines]
>
> Thanks for your understanding.

Actually the bug occurs in the design-time extensibility layer of VS2005.

I have written a data designer extensibility package for the SQLite database
engine.  During the course of testing this data designer, I've encountered a
design-time bug in the VS2005 Query Builder.  This bug also affects Sql
Server 2005's data designer.

If I were to post this in the dotnet.framework.adodotnet newsgroup, they'd
probably tell me this is a design-time issue and to go back to the
extensibility newsgroup.

Robert
Mythran - 12 Apr 2006 16:23 GMT
>> Hi Robert,
>>
[quoted text clipped - 30 lines]
>
> Robert

Actually, the bug is in the .Net IDE and occurs not in the extensibility
layer, but the IDE UI layer itself.  I would have x-posted this myself :P
Try microsoft.public.vstudio.general,
microsoft.public.dotnet.framework.adonet :)  And if it is duplicatable, I
would submit it as a bug after reading the responses from the other
newsgroups.

HTH,

Mythran
Robert Simpson - 17 Apr 2006 20:04 GMT
I wouldn't have posted here unless I'd already done my homework.

I have traced the bug as far as I could, down to
Microsoft.VSDesigner.DataSource.DesignParameter's constructor which takes an
ICQryAutoParameter and transforms the ICQueryAutoParameter.DataTypeInternal
property from an internal value to a DbType.

The class where ICQryAutoParameter came from is (I believe) in VDT80.DLL or
VDT70.DLL.

Now, this tool retrieves its internal datatype by doing some schema
retrieval and some unknown magic.  I know that GetSchema("DataTypes") is
called on the connection object, and DataReaders are constructed, and
GetSchemaTable() is called on them.  There are also calls into other schema
methods to retrieve Columns, Indexes, ReservedWords, etc on the connection.

In otherwords, there are some heavy-duty schema interactions and DDEX
provider interactions involved in bringing up the query builder, populating
the information inside of it, and finally up to the point where the
DesignParameter is constructed and a faulty DbType is populated within it.

So while visually I agree that this is a bug in the IDE, wherein you see a
faulty DbType -- the root of the problem lies in a vast interconnected layer
beneath it involving the data source, its DDEX provider, and the query
builder's underlying COM object.

So if you can provide me with a more appropriate forum than this one, please
let me know.  microsoft.public.dotnet.framework.adonet is definitely not it.

Robert

>>> Hi Robert,
>>>
[quoted text clipped - 41 lines]
>
> Mythran
"Gary Chang[MSFT]" - 20 Apr 2006 03:11 GMT
Hi Robert,

I do understand your concern on this issue, it appears we don't have an
appropriate managed newsgroup target on such a problem. There is one
managed newsgroup which discussed the winform design time issue, it may be
useful to you:

microsoft.public.dotnet.framework.windowsforms.designtime

Meantime, I highly suggest you can submit this problem to our product
feedback center, our development team may communicate with you directly on
the issue there:

http://lab.msdn.microsoft.com/productfeedback/default.aspx

Thanks for your understanding.

Best regards,

Gary Chang
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Reggie Burnett - 28 Jun 2006 00:19 GMT
Robert

Did you implement any custom designers for your db objects?  If so, what
method did you use for launching the custom designer?

>> Hi Robert,
>>
[quoted text clipped - 32 lines]
>
> Robert
Robert Simpson - 04 Jul 2006 18:04 GMT
My custom designers are wrappers around the built-in MS designers.  I've
worked around the bug I described earlier in the thread.

Robert

> Robert
>
[quoted text clipped - 37 lines]
>>
>> Robert
Reggie Burnett - 04 Jul 2006 18:50 GMT
I'm looking for info on the built in designers.  Is there a list of GUIDs
somewhere I can find?  What designers are available?

> My custom designers are wrappers around the built-in MS designers.  I've
> worked around the bug I described earlier in the thread.
[quoted text clipped - 42 lines]
>>>
>>> Robert
Robert Simpson - 04 Jul 2006 19:18 GMT
Technically, they're not available at all.  They are internal classes in
Microsoft.VSDesigner.DLL.  The only way to access them is through
reflection.

Download my SQLite provider source code and look at the SQLite.Interop
project to see how I wrapped some of the designers.  Others are directly
referenced in the System.Data.SQLite project.

http://sqlite.phxsoftware.com

Robert

> I'm looking for info on the built in designers.  Is there a list of GUIDs
> somewhere I can find?  What designers are available?
[quoted text clipped - 45 lines]
>>>>
>>>> Robert
Robert Simpson - 04 Jul 2006 19:23 GMT
Scratch that -- look in SQLite.Designer, not SQLite.Interop

> Technically, they're not available at all.  They are internal classes in
> Microsoft.VSDesigner.DLL.  The only way to access them is through
[quoted text clipped - 57 lines]
>>>>>
>>>>> Robert
Reggie Burnett - 04 Jul 2006 21:10 GMT
Thanks!  I'll have a look.

> Scratch that -- look in SQLite.Designer, not SQLite.Interop
>
[quoted text clipped - 60 lines]
>>>>>>
>>>>>> Robert

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.