Re: .NET data provider or OLEDB provider?

Thanks for your reply Bob,

I have had a preliminary look at both the .NET provider and OLEDB provider.
I agree that the .NET provider would be much simpler, but it looks like I
would have to write a query processing engine for the Command object. I have
noticed that with OLEDB there is already a Query Engine that can consume the
provider
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledb/htm/oledbprovmicrosoft_ole_db_providers_overview.asp)

If this is the case, then in theory at least I would only have to write (or
rather port) the data access methods and then plug them into the existing
OLEDB query engine. With .NET, I would have to write the a Query Engine that
understands at least a subset of ANSI-92!

All client side code will be written using .NET anyway, but it needs to be
SQL compatible so we can easily port the database to SQL Server at sometime
in the future.

I am finding it difficult to obtain sufficient information at the moment, so
any light you can shed on this would be much appreciated.

--
Best regards
Mark


"Bob Beauchemin" <no_bobb_spam@xxxxxxxxxxxxx> wrote in message
news:%23$$o57k3FHA.3588@xxxxxxxxxxxxxxxxxxxxxxx
> Hi Mark,
>
> Having taught an OLE DB provider class and written material on ADO.NET
> data providers.... (and written both)....
>
> An OLE DB provider will be infinately more difficult to write. And to get
> right. You can use it in a few more places (third party tools, SQL Server
> linked servers, etc). There's an OleDb .NET "bridge" provider, but it only
> supports a subset of OLE DB interfaces/properties.
>
> A .NET data provider would be *much* easier. The model is simpler and
> there are minimal (no) reference counting issues. I'd start with a .NET
> data provider. Only problem (which could be bigger for ISAM style
> database) is that the .NET model doesn't support scrollable, updateable
> cursors. .NET provider model is written after the client-server/three tier
> model where these are evil, so cursor support is left out. You could write
> your own extension classes, though.
>
> You could also write an ODBC driver, but the bridges (OLE DB provider for
> ODBC and .NET Odbc "bridge" provider) are pretty flakey and hard for folks
> (your clients) to work with. Some MS and third-party tools have dropped
> support for accessing ODBC drivers through the bridges.
>
> If you decide that Java is your only programming language/API environment,
> JDBC driver is the way to go.
>
> Oh, and there are third-party "your code goes here" toolkits/frameworks
> for building OLE DB/ODBC/JDBC. And ATL provider templates for OLE DB. I
> don't think there are toolkits for bulding ADO.NET data providers yet,
> maybe because its lots easier?
>
> Hope this helps,
> Bob Beauchemin
> http://www.SQLskills.com/blogs/bobb
>
>
> "Mark" <swozz_@xxxxxxxxxxx> wrote in message
> news:uTieN$j3FHA.3844@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi,
>>
>> We have a propriety database format currently in use by a DOS program.
>> There are some 1500 big customers using this system! The application that
>> sits on this database is complex and a rewrite would be a 2 year project
>> with massive upgrade/training issues at the end of it. This is why a
>> rewrite hasn't been commisioned - it's expensive and risky for a small
>> company to undertake even if it's 10 years overdue!
>>
>> To allow for a smoother less risky transition, we intend to rewrite the
>> front end using a combination of Windows/Web based technology (.NET)
>> whilst still utilizing the existing database. This will allow us the
>> gradually replace the front end. Once this is complete, we can port the
>> DOS database to something like SQL Server with relatively little
>> modifications required for the newly written front end.
>>
>> This means that we need SQL access to the existing DOS based ISAM style
>> data so that we can begin working on the new front end.
>>
>> The existing database was originally based on Borland Database Toolbox
>> (1985?) but has been significantly modified to work in a multiuser
>> environment.
>>
>> The way I see it, we could either write a .NET data provider or an OLEDB
>> provider.
>>
>> If we write a .NET data provider then we will also have to write a query
>> engine to support SQL type access. My question is that if we decide to
>> write an OLEDB provider to access the ISAM database, is there already a
>> Query Engine service that can take advantage of this provider to allow us
>> to access the data using SQL?
>>
>> Any help much appreciated...
>>
>> --
>> Best regards
>> Mark
>>
>>
>
>


.

Relevant Pages

  • Re: ADO connection with VBS to locally stored MS-Access database
    ... Even using of the OLEDB Jet provider is better, I do not see any confusion ... You could use ODBC or OLEDB syntax but in this case ADO will using ... > I am trying to connect to a local Access database via ADO and VB Script. ...
    (microsoft.public.data.ado)
  • Re: nVarchar limitations using OLEDB provider
    ... but not nvarcharor greater using a clientside cursor. ... is IMHO what OLEDB is designed for: ... Unless of course this OLEDB provider is not supported at all..... ... The issue may actually lie on the client code and not on the ...
    (microsoft.public.sqlserver.ce)
  • Re: How to write or replace a custom OLEDB provider
    ... the provider is returning a COM error number. ... their technical support refused to answer this question. ... OLEDB to make the data accessible to .NET applications and it can also be ...
    (microsoft.public.data.oledb)
  • Re: IIS, asp and a database
    ... the database, or set Data Source=a relative path using ... The Jet OLEDB Provider solves the problem. ... >> tradeoffs between the original driver and the new one? ...
    (microsoft.public.inetserver.asp.db)
  • ADO performance
    ... Sql database provider classes vs. the OleDb database provider classes. ...
    (microsoft.public.vb.database.ado)