Data access layer for SQL Server & MS Access

**RobinS** · Dec 8 '06, 05:45 AM

Re: Data access layer for SQL Server & MS Access

Yes. (You can use OLEDB for both database types.)

Robin S.
------------------
<sanders_mike_n ewsgroups@yahoo .comwrote in message
news:1165557636 .003154.70940@f 1g2000cwa.googl egroups.com...

Hi
>
I have a web app that needs to be able to use either SQL Server or MS
Access - depending upon the installation. I want to avoid having
unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
OLEDBDatareader in lots of parts of the app)
>
Could I not just avoid this and use OLEDB for both database types?
>
Whats the best way - OLEDB or to create some kind of data access layer
that returns recordsets.
>
Thanks
Mike
>

**sanders_mike_newsgroups@yahoo.com** · Dec 8 '06, 06:55 AM

Re: Data access layer for SQL Server & MS Access

OK, thanks for that.

RobinS wrote:

Yes. (You can use OLEDB for both database types.)
>
Robin S.
------------------
<sanders_mike_n ewsgroups@yahoo .comwrote in message
news:1165557636 .003154.70940@f 1g2000cwa.googl egroups.com...

Hi

I have a web app that needs to be able to use either SQL Server or MS
Access - depending upon the installation. I want to avoid having
unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
OLEDBDatareader in lots of parts of the app)

Could I not just avoid this and use OLEDB for both database types?

Whats the best way - OLEDB or to create some kind of data access layer
that returns recordsets.

Thanks
Mike

**Master Programmer** · Dec 8 '06, 07:15 AM

Re: Data access layer for SQL Server & MS Access

Dont listen to this guy, he just posts messages around these groups
trying to cause trouble and give people the wrong information.

You need to create a custom "Data Access Class" that obscures the type
of database that you are connecting to. OLEDB is way too slow (100
times slower than a native SQL Server connection).

To be honest with the limitations of the .net data tools (IE: no
generic dataReader etc) - you are probably better to keep life simple.
I don't mean to be blasphemous but just import ADO (COM) and use that -
at least it has MoveNext.

The Grand Master
"Visual Basic 6.0 Jihad"

sanders_mike_ne wsgroups@yahoo. com wrote:

Hi
>
I have a web app that needs to be able to use either SQL Server or MS
Access - depending upon the installation. I want to avoid having
unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
OLEDBDatareader in lots of parts of the app)
>
Could I not just avoid this and use OLEDB for both database types?
>
Whats the best way - OLEDB or to create some kind of data access layer
that returns recordsets.
>
Thanks
Mike

**RobinS** · Dec 8 '06, 07:25 AM

Re: Data access layer for SQL Server & MS Access

We both know that's not true. You are the one who is flaming people,
as anyone can tell by your history. You could at least maintain
a modicum of class and not tell lies about other people.

Robin S.
-----------------
"Master Programmer" <master_program mer@outgun.comw rote in message
news:1165563227 .558862.152350@ 79g2000cws.goog legroups.com...

Dont listen to this guy, he just posts messages around these groups
trying to cause trouble and give people the wrong information.
>
You need to create a custom "Data Access Class" that obscures the type
of database that you are connecting to. OLEDB is way too slow (100
times slower than a native SQL Server connection).
>
To be honest with the limitations of the .net data tools (IE: no
generic dataReader etc) - you are probably better to keep life simple.
I don't mean to be blasphemous but just import ADO (COM) and use that -
at least it has MoveNext.
>
The Grand Master
"Visual Basic 6.0 Jihad"
>
>
sanders_mike_ne wsgroups@yahoo. com wrote:

>Hi
>>
>I have a web app that needs to be able to use either SQL Server or MS
>Access - depending upon the installation. I want to avoid having
>unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
>OLEDBDatareade r in lots of parts of the app)
>>
>Could I not just avoid this and use OLEDB for both database types?
>>
>Whats the best way - OLEDB or to create some kind of data access layer
>that returns recordsets.
>>
>Thanks
>Mike

>

**Rotsey** · Dec 8 '06, 11:45 AM

Re: Data access layer for SQL Server & MS Access

the perforamnce of using OLEDB with SQL is pretty poor on all reports.

<sanders_mike_n ewsgroups@yahoo .comwrote in message
news:1165561986 .428411.324020@ j72g2000cwa.goo glegroups.com.. .

OK, thanks for that.
>
>
RobinS wrote:

>Yes. (You can use OLEDB for both database types.)
>>
>Robin S.
>------------------
><sanders_mike_ newsgroups@yaho o.comwrote in message
>news:116555763 6.003154.70940@ f1g2000cwa.goog legroups.com...

Hi
>
I have a web app that needs to be able to use either SQL Server or MS
Access - depending upon the installation. I want to avoid having
unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
OLEDBDatareader in lots of parts of the app)
>
Could I not just avoid this and use OLEDB for both database types?
>
Whats the best way - OLEDB or to create some kind of data access layer
that returns recordsets.
>
Thanks
Mike
>

>

**rowe_newsgroups** · Dec 8 '06, 01:55 PM

Re: Data access layer for SQL Server & MS Access

To be honost I've never had any performance trouble using OleDb with
SQL server - it all depends on what you're doing and how often. The OP
should do some speed checks between the two (SQLClient and OleDb) and
see if the difference is enough to warrant using OleDb for Access, and
SQLClient for SQL Server or just using OleDb for both.

Also, if I'm not mistaking, isn't the OleDb class just a wrapper for
"classic" ADO? If so you wouldn't gain much (if anything) by using ADO
instead of ADO.Net

Thanks,

Seth Rowe

Rotsey wrote:

the perforamnce of using OLEDB with SQL is pretty poor on all reports.
>
>
<sanders_mike_n ewsgroups@yahoo .comwrote in message
news:1165561986 .428411.324020@ j72g2000cwa.goo glegroups.com.. .

OK, thanks for that.

RobinS wrote:

Yes. (You can use OLEDB for both database types.)
>
Robin S.
------------------
<sanders_mike_n ewsgroups@yahoo .comwrote in message
news:1165557636 .003154.70940@f 1g2000cwa.googl egroups.com...
Hi

I have a web app that needs to be able to use either SQL Server or MS
Access - depending upon the installation. I want to avoid having
unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
OLEDBDatareader in lots of parts of the app)

Could I not just avoid this and use OLEDB for both database types?

Whats the best way - OLEDB or to create some kind of data access layer
that returns recordsets.

Thanks
Mike

BK · Dec 8 '06, 02:25 PM

Re: Data access layer for SQL Server & MS Access

We use a custom class we wrote in house that puts all our data access
in a wrapper. That way, the whole shop uses the same syntax for data
access regardless of the backend. We use it for access to Oracle, SQL
Server (2000 and 2005), DB2, and even MySql when we want a disconnected
database. The Enterprise Library Data Access is nice and we gave some
consideration to it before committing to "roll our own", but the
support for DB2 was lacking (unless you purchase additional product
from IBM) and there was no support for MySql. It's worth looking at
any way.

As for "Master Programmer"'s comments.... that's a bit like the pot
calling the kettle black. He's one of 2 that are constantly trying to
stir up trouble, disregard his comments. For a quick sampling of his
typical childish rants, look at some of these posts (there are plent
others):

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/browse_frm/thread/76b98908a46c4235/ed1a354a0360e19e#ed1a354a0360e19e

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/browse_frm/thread/e38d7018d85872e1/6533cc9c33358562#6533cc9c33358562

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/browse_frm/thread/2ce097ad4cf0b8a9/5dd479d77fe43e53?lnk=st&q=&rnum=31#5dd479d77fe43e53

http://groups.google.com/group/microsoft.public.excel/browse_frm/thread/aad27a7884a4a7/453a4a8dcaf35681?lnk=st&q=&rnum=43#453a4a8dcaf35681

**aaron.kempf@gmail.com** · Dec 8 '06, 11:05 PM

Re: Data access layer for SQL Server & MS Access

Robin;

can it; MP is always right

Just use ADO; that's my vote.

ADO.net is _CRAP_

-Aaron

RobinS wrote:

We both know that's not true. You are the one who is flaming people,
as anyone can tell by your history. You could at least maintain
a modicum of class and not tell lies about other people.
>
Robin S.
-----------------
"Master Programmer" <master_program mer@outgun.comw rote in message
news:1165563227 .558862.152350@ 79g2000cws.goog legroups.com...

Dont listen to this guy, he just posts messages around these groups
trying to cause trouble and give people the wrong information.

You need to create a custom "Data Access Class" that obscures the type
of database that you are connecting to. OLEDB is way too slow (100
times slower than a native SQL Server connection).

To be honest with the limitations of the .net data tools (IE: no
generic dataReader etc) - you are probably better to keep life simple.
I don't mean to be blasphemous but just import ADO (COM) and use that -
at least it has MoveNext.

The Grand Master
"Visual Basic 6.0 Jihad"

sanders_mike_ne wsgroups@yahoo. com wrote:

Hi
>
I have a web app that needs to be able to use either SQL Server or MS
Access - depending upon the installation. I want to avoid having
unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
OLEDBDatareader in lots of parts of the app)
>
Could I not just avoid this and use OLEDB for both database types?
>
Whats the best way - OLEDB or to create some kind of data access layer
that returns recordsets.
>
Thanks
Mike

**RobinS** · Dec 9 '06, 03:05 AM

Re: Data access layer for SQL Server & MS Access

MP is not always right. He has the right to post
whatever opinions he has about technical issues.
He does *not* have the right to tell lies about
me and to slur my character.

Robin S.
--------------------------
<aaron.kempf@gm ail.comwrote in message
news:1165620314 .850827.326200@ 80g2000cwy.goog legroups.com...

Robin;
>
can it; MP is always right
>
Just use ADO; that's my vote.
>
ADO.net is _CRAP_
>
-Aaron
>
>
RobinS wrote:

>We both know that's not true. You are the one who is flaming people,
>as anyone can tell by your history. You could at least maintain
>a modicum of class and not tell lies about other people.
>>
>Robin S.
>-----------------
>"Master Programmer" <master_program mer@outgun.comw rote in message
>news:116556322 7.558862.152350 @79g2000cws.goo glegroups.com.. .

Dont listen to this guy, he just posts messages around these groups
trying to cause trouble and give people the wrong information.
>
You need to create a custom "Data Access Class" that obscures the type
of database that you are connecting to. OLEDB is way too slow (100
times slower than a native SQL Server connection).
>
To be honest with the limitations of the .net data tools (IE: no
generic dataReader etc) - you are probably better to keep life simple.
I don't mean to be blasphemous but just import ADO (COM) and use that -
at least it has MoveNext.
>
The Grand Master
"Visual Basic 6.0 Jihad"
>
>
sanders_mike_ne wsgroups@yahoo. com wrote:
>Hi
>>
>I have a web app that needs to be able to use either SQL Server or MS
>Access - depending upon the installation. I want to avoid having
>unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
>OLEDBDatareade r in lots of parts of the app)
>>
>Could I not just avoid this and use OLEDB for both database types?
>>
>Whats the best way - OLEDB or to create some kind of data access layer
>that returns recordsets.
>>
>Thanks
>Mike
>

>

**aaron.kempf@gmail.com** · Dec 11 '06, 04:05 AM

Re: Data access layer for SQL Server & MS Access

nor do you of him

-aaron

RobinS wrote:

MP is not always right. He has the right to post
whatever opinions he has about technical issues.
He does *not* have the right to tell lies about
me and to slur my character.
>
Robin S.
--------------------------
<aaron.kempf@gm ail.comwrote in message
news:1165620314 .850827.326200@ 80g2000cwy.goog legroups.com...

Robin;

can it; MP is always right

Just use ADO; that's my vote.

ADO.net is _CRAP_

-Aaron

RobinS wrote:

We both know that's not true. You are the one who is flaming people,
as anyone can tell by your history. You could at least maintain
a modicum of class and not tell lies about other people.
>
Robin S.
-----------------
"Master Programmer" <master_program mer@outgun.comw rote in message
news:1165563227 .558862.152350@ 79g2000cws.goog legroups.com...
Dont listen to this guy, he just posts messages around these groups
trying to cause trouble and give people the wrong information.

You need to create a custom "Data Access Class" that obscures the type
of database that you are connecting to. OLEDB is way too slow (100
times slower than a native SQL Server connection).

To be honest with the limitations of the .net data tools (IE: no
generic dataReader etc) - you are probably better to keep life simple.
I don't mean to be blasphemous but just import ADO (COM) and use that -
at least it has MoveNext.

The Grand Master
"Visual Basic 6.0 Jihad"

sanders_mike_ne wsgroups@yahoo. com wrote:
Hi
>
I have a web app that needs to be able to use either SQL Server or MS
Access - depending upon the installation. I want to avoid having
unnessesary amounts of code (eg: dim x as sqlDataReader, dim y as
OLEDBDatareader in lots of parts of the app)
>
Could I not just avoid this and use OLEDB for both database types?
>
Whats the best way - OLEDB or to create some kind of data access layer
that returns recordsets.
>
Thanks
Mike

**RobinS** · Dec 11 '06, 04:15 AM

Re: Data access layer for SQL Server & MS Access

Granted. And I haven't. I have just stated that I
disagreed with him. At least, that's what I've tried
to do. Since I don't know him, or you, I can't say
anything about either of you except in regards to
your behavior in this newsgroup.

Robin S.
-----------------

<aaron.kempf@gm ail.comwrote in message
news:1165811490 .268036.163900@ 79g2000cws.goog legroups.com...

nor do you of him
>
-aaron
>
>
RobinS wrote:

>MP is not always right. He has the right to post
>whatever opinions he has about technical issues.
>He does *not* have the right to tell lies about
>me and to slur my character.
>>
>Robin S.
>--------------------------
><aaron.kempf@g mail.comwrote in message
>news:116562031 4.850827.326200 @80g2000cwy.goo glegroups.com.. .

Robin;
>
can it; MP is always right
>
Just use ADO; that's my vote.
>
ADO.net is _CRAP_
>
-Aaron
>
>
RobinS wrote:
>We both know that's not true. You are the one who is flaming
>people,
>as anyone can tell by your history. You could at least maintain
>a modicum of class and not tell lies about other people.
>>
>Robin S.
>-----------------
>"Master Programmer" <master_program mer@outgun.comw rote in
>message
>news:116556322 7.558862.152350 @79g2000cws.goo glegroups.com.. .
Dont listen to this guy, he just posts messages around these
groups
trying to cause trouble and give people the wrong information.
>
You need to create a custom "Data Access Class" that obscures
the type
of database that you are connecting to. OLEDB is way too slow
(100
times slower than a native SQL Server connection).
>
To be honest with the limitations of the .net data tools (IE: no
generic dataReader etc) - you are probably better to keep life
simple.
I don't mean to be blasphemous but just import ADO (COM) and use
that -
at least it has MoveNext.
>
The Grand Master
"Visual Basic 6.0 Jihad"
>
>
sanders_mike_ne wsgroups@yahoo. com wrote:
>Hi
>>
>I have a web app that needs to be able to use either SQL Server
>or MS
>Access - depending upon the installation. I want to avoid
>having
>unnessesary amounts of code (eg: dim x as sqlDataReader, dim y
>as
>OLEDBDatareade r in lots of parts of the app)
>>
>Could I not just avoid this and use OLEDB for both database
>types?
>>
>Whats the best way - OLEDB or to create some kind of data
>access layer
>that returns recordsets.
>>
>Thanks
>Mike
>
>

>

Data access layer for SQL Server & MS Access

Data access layer for SQL Server & MS Access

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment