LLBL runs slow with MS Access Database?

Posts   
 
    
sun450
User
Posts: 4
Joined: 07-Dec-2004
# Posted on: 01-Jul-2007 09:28:44   

Hi, I am using v2.0, released on 2006, oct, 23rd.

I generate the code using SQL server tables, they are running good and fast. Now I migrate the SQL server tables into MS Access for the portability. After I transfer the tables and data and relationships, I generate the code.

Now all other parts of the programs are same except the code generated from LLBL. The problem is that to get some data (say 100 records) from MS Access is very slow.

I had the same problem before, when I want to read 1000 records from MS Access using LLBL, but I give up because the performance is so bad.

I don't know is there a way to fine tune the performance?

Hope can get ur reply soon, need do a good demo for the client soon. Thanks for the help.

DvK
User
Posts: 323
Joined: 22-Mar-2006
# Posted on: 01-Jul-2007 11:16:04   

Please use the latest release version, just to make sure.

I use LLBL on both platforms (SQL + Access) and never experienced a true performance difference, definitely not on a 100/1000 rows.

Important difference though is that Access (Jet) is running a local "database-engine" and SQL possibly is not (assuming it's on a different machine)...so that could lead to a minor performance degradation. Are the generated queries by LLBL also slow when they're being executed in Access itself ? You can send the query output to your output window by setting some tracers in your app.config.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39912
Joined: 17-Aug-2003
# Posted on: 01-Jul-2007 12:19:55   

Also check if your hdd isn't fragmented. MS access should run OK, it's of course not as fast as sqlserver, but it shouldn't be that noticable in fetching small sets.

Frans Bouma | Lead developer LLBLGen Pro
sun450
User
Posts: 4
Joined: 07-Dec-2004
# Posted on: 02-Jul-2007 20:23:42   

I checked in details and use dotTrace to look at the running time.

The slow is due the following: 1 links with 2 step relations, table1 -> table2 -> table3. If I call, table1.table3viaTable2, it is very slow in access LLBL. now I changed to table1.table2, the speed is much better.

2 creation of GUID-keyed entity, 100.00 % InitClassFetch - 29236 ms - 568 calls - EQAS.DAL.EntityClasses.SystemEntityBase.InitClassFetch(Guid, IValidator, IPrefetchPath)

but if I use the SQL LLBL, the speed is much much better. So does it mean I need to use the latest version of LLBL? any other hints for the issue number 2, 3?

If I upgrade to latest version, is any problems for the generated code? Thanks

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 03-Jul-2007 10:43:34   

So does it mean I need to use the latest version of LLBL?

It's better to always stay updated with the latest version, you version is old. And many issues were solved since then. So for the sake it, try to use the latest build/version available.

any other hints for the issue number 2, 3?

I don't see issue #3

If I upgrade to latest version, is any problems for the generated code?

None.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39912
Joined: 17-Aug-2003
# Posted on: 04-Jul-2007 10:07:53   

sun450 wrote:

I checked in details and use dotTrace to look at the running time.

The slow is due the following: 1 links with 2 step relations, table1 -> table2 -> table3. If I call, table1.table3viaTable2, it is very slow in access LLBL. now I changed to table1.table2, the speed is much better.

The 'viaTableX' are m:n relations, so they will do a join. This can be slow(er) on db's like Access if you have a lot of data in the db

Frans Bouma | Lead developer LLBLGen Pro