[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.odbcnet

ODBC .NET and other managed providers

Karen Ploski

5/31/2002 7:01:00 PM

The ODBC .NET provider must be downloaded and installed
after the .NET framework is installed. I'm able to add a
Data Connection to an ODBC source, and the database
appears in Server Explorer. But, I'm not able to expand
the Tables or Views node. Menu entries, such as "New
Table" and "New View" do not appear when I right-click on
these nodes for the ODBC source. Also, the "Database
Diagrams" node does not appear under the ODBC Source.

Also, when I drag and drop the OdbcDataAdapter to the
Component Designer tray the Data Adapter Wizard is not
launched. But it is launched for the OleDbDataAdapter
and the SqlDataAdapter

Questions:
(1) Will the ODBC .NET provider be intergrated into the
Visual Studio IDE in the future--will the drag-and-drop
actions and menu entries available now for OleDb and SQL
be added for ODBC?
(2)Will Visual Studio .NET recognize other managed
providers for different databases and make these actions
and menu entries available for them as well as for ODBC,
OleDb and SQL?
5 Answers

(Malcolm Stewart)

5/31/2002 8:15:00 PM

0

Bob Beauchemin

5/31/2002 9:35:00 PM

0

Publishing the code-generation algorithms/codepaths or a generic codepath
(for data provider writers) and letting the data provider writers work
around it would be an acceptable compromise. These can't be secret, as you
can deduce them now by running VS.NET with SQL Profiler turned on. If
producing invalid wizard code is a problem data provider writers can't work
around, it would then be their problem.

Leaving out third-party providers currently (including Odbc at present) just
"causes unrest". And makes lack of possible Visual Studio intergration one
less reason to write a data provider. I do realize it could be a support
issue (but lack of support probably is also one, at present).

Cheers,
Bob Beauchemin
bobb@develop.com



"Malcolm Stewart" <malcolms@online.microsoft.com> wrote in message
news:#qs9O8MCCHA.1720@cpmsftngxa07...
> Karen,
>
> <<
> Will the ODBC .NET provider be intergrated into the Visual Studio IDE in
> the future--will the drag-and-drop actions and menu entries available now
> for OleDb and SQL be added for ODBC?
> >>
>
> That is the plan of record, though there are no guarantees.
>
> <<
> Will Visual Studio .NET recognize other managed providers for different
> databases and make these actions and menu entries available for them as
> well as for ODBC, OleDb and SQL?
> >>
>
> The next major release should incorporate the ODBC, Oracle, and other
> Providers from Microsoft. Currently, these are baked into the Server
> Provider and cannot really be extended. This may be opened up in the
> future, but there are a number of issues even with some OLE DB Providers,
> such as how to produce SQL that may have minor variations from Provider to
> Provider. Currently, SQL Server, Jet, and Oracle have different code paths
> in the UI tool.
>
> Malcolm Stewart
> Microsoft Developer Support
> This posting is provided "AS IS", with no warranties, and confers no
rights.
>
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.co....

(Malcolm Stewart)

6/4/2002 5:00:00 PM

0

Bob Beauchemin

6/9/2002 3:34:00 AM

0

Thanks, Malcolm, I appreciate your actions. And potential data provider
writers do as well.

I'll have to admit I'm a bit put off when I hear that certain large software
companies don't listen to (or solicit) feedback from their customers. Just
look around. This is but a single occurence...

BTW, I didn't only ask for Server Explorer, I'm talking about the "drag and
drop" Data component tab in Visual Studio more than server explorer. I want
to add the <your provider goes here> Connection, Command, and DataAdapter to
the Data tab and be able to use 'em with items that inherit from Component.
And the equivalent of OLE DB's DataLinks API or ODBC's SqlBrowseConnect for
.NET data providers (for use in VS). Those are both as important (IMHO) than
Server Explorer.

But that's only one voice.

Bob Beauchemin
bobb@develop.com


"Malcolm Stewart" <malcolms@online.microsoft.com> wrote in message
news:gxU4vh9CCHA.2528@cpmsftngxa08...
> Bob,
>
> <<
> Publishing the code-generation algorithms/codepaths or a generic codepath
> (for data provider writers) and letting the data provider writers work
> around it would be an acceptable compromise. These can't be secret, as you
> can deduce them now by running VS.NET with SQL Profiler turned on. If
> producing invalid wizard code is a problem data provider writers can't
work
> around, it would then be their problem.
>
> Leaving out third-party providers currently (including Odbc at present)
just
> "causes unrest". And makes lack of possible Visual Studio intergration one
> less reason to write a data provider. I do realize it could be a support
> issue (but lack of support probably is also one, at present).
> >>
>
> I've submitted your request. Of course, this will be influenced by
numbers,
> so if anyone else feels strongly about getting a Managed Provider SDK that
> includes Server Explorer integration, you should e-mail mswish at
> you-know-where and clearly spell out the product (Visual Studio .NET) and
> technology (Server Explorer, ADO.NET Managed Provider SDK) so it gets to
> the right DEV group, and let your wishes (and numbers). be known.
>
> Malcolm Stewart
> Microsoft Developer Support
> This posting is provided "AS IS", with no warranties, and confers no
rights.
>
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.co....

Karen Ploski

6/10/2002 3:16:00 PM

0

This discussion is interesting. Having spent quite a bit of time recently working in the Visual Studio .NET IDE and using the ODBC .NET provider, I must say I'm looking forward to the next release of Visual Studio .NET. I also believe that a Managed Provider SDK that includes Server Explorer integration would be a big plus.
Bob's suggestion/request, which involved the ability to place <you-name-it> Connection, Command, and DataAdapter objects on the Data tray is very interesting and has a lot of merit, in my opinion.