Data access layer for SQL Server & MS Access

[sanders_mike_newsgroups]

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]

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

Robin S.
------------------
<sa*********************@yahoo.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.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]

OK, thanks for that.
RobinS wrote:

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

Robin S.
------------------
<sa*********************@yahoo.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.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]

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"
sa*********************@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]

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" <ma***************@outgun.comwrote in message
news:11**********************@79g2000cws.googlegro ups.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"
sa*********************@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

[Rotsey]

the perforamnce of using OLEDB with SQL is pretty poor on all reports.
<sa*********************@yahoo.comwrote in message
news:11**********************@j72g2000cwa.googlegr oups.com...

OK, thanks for that.
RobinS wrote:

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

Robin S.
------------------
<sa*********************@yahoo.comwrote in message
news:11*********************@f1g2000cwa.googlegro ups.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]

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.
<sa*********************@yahoo.comwrote in message
news:11**********************@j72g2000cwa.googlegr oups.com...

OK, thanks for that.
RobinS wrote:

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

Robin S.
------------------
<sa*********************@yahoo.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.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]

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/micro...1a354a0360e19e
http://groups.google.com/group/micro...33cc9c33358562
http://groups.google.com/group/micro...d479d77fe43e53
http://groups.google.com/group/micro...3a4a8dcaf35681

[aaron.kempf]

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" <ma***************@outgun.comwrote in message
news:11**********************@79g2000cws.googlegro ups.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"
sa*********************@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]

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.
--------------------------
<aa*********@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.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" <ma***************@outgun.comwrote in message
news:11**********************@79g2000cws.googlegr oups.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"
sa*********************@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

[aaron.kempf]

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.
--------------------------
<aa*********@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.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" <ma***************@outgun.comwrote in message
news:11**********************@79g2000cws.googlegro ups.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"
sa*********************@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]

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.
-----------------

<aa*********@gmail.comwrote in message
news:11**********************@79g2000cws.googlegro ups.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.
--------------------------
<aa*********@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegr oups.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" <ma***************@outgun.comwrote in
message
news:11**********************@79g2000cws.googlegr oups.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"
sa*********************@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