[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.odbcnet

.NET and MSAccess database == SLOW

Joe Tobey

11/5/2002 3:47:00 PM

I'm considering migrating an application to .NET but I'm finding it takes
about 10 times longer to write records to an Access db than my VS 6 app
which used DAO. For my .NET test I'm using OleDbConnection and
OleDbDataAdapter classes as follows:

WriteRecords()
{
oleDbConnection1.Open()

for {each record}
oleDbDataAdapter1.InsertCommand.CommandText = "INSERT INTO ...."
oleDBDataAdapter1.ExecuteNonQuery()
}

oleDbConnection1.Close()
}


My application doesn't use a DataView, and its not clear to me if I should
be using a DataSet. I tend to have 10 or 15 different tables some of which
get a single record added and others which get multiple records added
(approx 100-400 records) per transaction.

Is there a more efficient way for writing multiple records to a database?

In general, I'm having a difficult time understanding what my various
options for database interaction are.

Thanks,
Joe


6 Answers

Joe Tobey

11/5/2002 3:51:00 PM

0

I probably should have mentioned that this not a web application, just a fat
Windows app.


(Scot Rose)

11/5/2002 5:09:00 PM

0

>I'm considering migrating an application to .NET but I'm finding it takes
>about 10 times longer to write records to an Access db than my VS 6 app
>which used DAO.

You are finding out what those of use that used ADO with Jet database discovered when VB6 first came out... Yes, ADO (and ADO.Net) are slower with Access
databases than DAO.. There is usually around a 30% performance hit on the last benchmarks I saw, but I think it was improved some over time. Keep in mind,
ADO is designed as a General Purpose data Access tool, whereas DAO was Jets own Native language so to speak, so it tends to slow things down..

As far as your code It looks fine from what you placed in your note, as to using a DataSet, I think it would probably be quicker to do that than to loop through and
do inserts in the way you are doing, even though basically thats what it will be doing behind the scenes, its code is a bit faster than looping (Anyone else, correct
me if I am wrong on that as I haven't actually tested it)

Want to know more? Check out the MSDN Library at http://msdn.mic... or the Microsoft Knowledge Base at http://support.mic...

Scot Rose, MCSD
Microsoft Visual Basic Developer Support
Email : scotr@online.microsoft.com <Remove word online. from address>

This posting is provided “AS IS”, with no warranties, and confers no rights.





(Steven Bras [MS])

11/5/2002 7:09:00 PM

0

In Visual Studio .Net, your options are either ADO, via COM Interop, or
ADO.Net with OLEDB using the JetOLEDB Provider and the System.Data.Oledb
objects, or the ODBC provider using the Access ODBC driver. DAO is not
supported.

ADO is known to be slower, with Access databases, than DAO. DAO was
designed specifically for Jet databases, and is optimized for them. ADO, on
the other hand, is designed to handle many different databases, most of
which are server-based like SQL Server or Oracle.

A couple of Microsoft Knowledge Base articles may be of interest:

Q225048 INFO: Issues Migrating from DAO/Jet to ADO/Jet
http://support.microsoft.com/default.aspx?scid=kb;EN-...

Q240434 HOWTO: Improve Performance of Applications Using Jet 4.0
http://support.microsoft.com/default.aspx?scid=kb;EN-...

If you are using the Jet OLEDB Provider 4.0 and your database is Access 97
or earlier, you may wish to switch to the Jet OLEDB 3.51 provider. This
provider does not use Unicode, and is slightly faster with older database
formats.

The coding technique you are using is probably the most efficient way to go
about adding the rows to the database.

Hope this information helps!

Steven Bras, MCSD
Microsoft Developer Support/Visual Basic WebData

This posting is provided "AS IS" with no warranties, and confers no rights.

Are you secure? For information about the Microsoft Strategic Technology
Protection Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.co....

Bruce L-C

11/5/2002 7:24:00 PM

0

I can think of one thing right now that will make a big big difference. Wrap
them in a transaction. You can play with the number of records but I usually
do 100 records and then commit. Right now, every insert is a single
transaction.

Also, I disagree with the comment about ADO being slower than DAO. I
converted from DAO to ADO a long time ago and did not see this. True, at
first you had to use the OLEDB->ODBC route but with a native OLEDB provider
for ADO this issue went away (an extra level of indirection). Anyway, try
wrapping it in a transaction and see if it gets faster.

Bruce L-C

"Joe Tobey" <tobeyj@biotek.com> wrote in message
news:#wUm6oNhCHA.2636@tkmsftngp08...
> I'm considering migrating an application to .NET but I'm finding it takes
> about 10 times longer to write records to an Access db than my VS 6 app
> which used DAO. For my .NET test I'm using OleDbConnection and
> OleDbDataAdapter classes as follows:
>
> WriteRecords()
> {
> oleDbConnection1.Open()
>
> for {each record}
> oleDbDataAdapter1.InsertCommand.CommandText = "INSERT INTO ...."
> oleDBDataAdapter1.ExecuteNonQuery()
> }
>
> oleDbConnection1.Close()
> }
>
>
> My application doesn't use a DataView, and its not clear to me if I should
> be using a DataSet. I tend to have 10 or 15 different tables some of
which
> get a single record added and others which get multiple records added
> (approx 100-400 records) per transaction.
>
> Is there a more efficient way for writing multiple records to a database?
>
> In general, I'm having a difficult time understanding what my various
> options for database interaction are.
>
> Thanks,
> Joe
>
>


Ted

12/4/2002 5:34:00 PM

0

Steven,

If Ado.Net or Ado is an option in VS.Net via COM Interop.
Would VBA also become an option?

Ted

>-----Original Message-----
>In Visual Studio .Net, your options are either ADO, via
COM Interop, or
>ADO.Net with OLEDB using the JetOLEDB Provider and the
System.Data.Oledb
>objects, or the ODBC provider using the Access ODBC
driver. DAO is not
>supported.
>
>ADO is known to be slower, with Access databases, than
DAO. DAO was
>designed specifically for Jet databases, and is optimized
for them. ADO, on
>the other hand, is designed to handle many different
databases, most of
>which are server-based like SQL Server or Oracle.
>
>A couple of Microsoft Knowledge Base articles may be of
interest:
>
>Q225048 INFO: Issues Migrating from DAO/Jet to ADO/Jet
>http://support.microsoft.com/default.aspx?s...
US;Q225048
>
>Q240434 HOWTO: Improve Performance of Applications Using
Jet 4.0
>http://support.microsoft.com/default.aspx?s...
US;Q240434
>
>If you are using the Jet OLEDB Provider 4.0 and your
database is Access 97
>or earlier, you may wish to switch to the Jet OLEDB 3.51
provider. This
>provider does not use Unicode, and is slightly faster
with older database
>formats.
>
>The coding technique you are using is probably the most
efficient way to go
>about adding the rows to the database.
>
>Hope this information helps!
>
>Steven Bras, MCSD
>Microsoft Developer Support/Visual Basic WebData
>
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>
>Are you secure? For information about the Microsoft
Strategic Technology
>Protection Program and to order your FREE Security Tool
Kit, please visit
>http://www.microsoft.co....
>
>.
>

(Steven Bras [MS])

12/5/2002 5:51:00 PM

0

VBA is not a replacement for ADO or ADO.Net; VBA is the "flavor" of Visual
Basic usually bundled with applications as a macro language. Of course, you
can call VBA scripts from VB.Net, but usually not for the purpose of
database access.

Have I understood your question correctly?

Steven Bras, MCSD
Microsoft Developer Support/Visual Basic WebData

This posting is provided "AS IS" with no warranties, and confers no rights.

Are you secure? For information about the Microsoft Strategic Technology
Protection Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.co....