Access .accdb file size issues

I have a client server application where both the front and back end databases are in excess of 1 GB. Lately, I have been running some functions that create an Excel object and populate it - sometimes with several thousand rows of data - and both my front end and back end .accdbs explode up to 1.8 - 2 GB, which makes them crash.

I have added "compact on close" to my database settings and eventually plan to move the back end to MS SQL Express, but I don't have much experience with MS SQL and until I get a little experience using it I don't want to make the move because my department depends on these applications. I am also wondering if memory problems on my computer may be causing the database problems.

Any suggestions will be appreciated.

Thanks.
Buck_BeasomDatabase DesignerAsked:
Who is Participating?
 
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
Memory should not make a difference, but there are two things which you can do which should:

1. For any query you use that adds,deletes, or updates, make sure the UseTransaction property is set to no.

2. If your using temp tables, consider using a temp database.  Create another DB when the import process starts, create tables in it using the TransferDatabase method (you keep a blank table in the current DB as a template), and then have a link to the temp DB.

  You can then use the temp tables and as soon as your done, delete the temp DB.  

  Sounds like a lot, but it really requires very little work to setup.

Jim.
0
 
Buck_BeasomDatabase DesignerAuthor Commented:
Thank you. The application launches 19 queries and virtually all of them are add, delete or update queries. I will do as you suggest and get back with the results in the AM.
0
 
Buck_BeasomDatabase DesignerAuthor Commented:
It helped some, but the app file still jumped up by almost half a gig. I am executing a bunch of embedded queries in the code. Is there something I can do with those queries to make them launch with "UseTransaction" set to no? I am using the DoCmd.RunSQL method.

Thanks.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
I don't think there's much you can do about that. When you're manipulating data, you're going to bloat the database.

As JimD suggests, you can use an external database to do your manipulations, and then Import the finished data to your live database (and then compact that). You can then delete the temporary database, and recreate it as needed.
0
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
"where both the front and back end databases "
"I have added "compact on close" to my database settings"
Unless you are manually opening and closing the db with C on C set, nothing will happen. For example, if you have C on C set on the backend, and you are running these processes from the front end - linked (or otherwise) to the back end,  then C on C does nothing.
Just an FYI.
0
 
Buck_BeasomDatabase DesignerAuthor Commented:
I tried to split the points up to recognise that Jim's solution gave me the best results, but that I appreciate the other input. I am aware that C on C in the Front End will not impact the back end and I am investigating ways to do auto-compact to the back end. It's obvious I'm going to need some creativity until I can get this onto MS SQL - probably multiple front and back ends. There are multiple issues - size of the files, extent of the application and the fact that I can't join tables in two different back ends. (Or if I can, I still have to figure it out.)

In any event, thanks to all.
0
 
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<I am aware that C on C in the Front End will not impact the back end and I am investigating ways to do auto-compact to the back end.>>

  You can call for a compact on the BE through DAO as long as:

1. No other users are in the BE

2. The current FE has no connections to the BE.

  Being that it is data only, there's no problem calling for a compact through JET.  

Jim.

    ' Do we need to do a compact?
    If intCallCompact = True Then
   
      ' Close forms recordset
      Call AddLineToLog("Compact Back End - Disconnecting")
     
      strDBPath = GetAttachedPath_TSB("", "tblErrors")
      strDBPath = Left$(strDBPath, Len(strDBPath) - 12)
     
      ' Make sure a copy of the compacted MDB does not exist.
      KillFile_TSB (strDBPath & "NETCPTMP.MDB")
     
      ' Do a compact on the BE database.
      Call AddLineToLog("Compact Back End - Compacting")
      DBEngine.CompactDatabase strDBPath & "NETCPDAT.MDB", strDBPath & "NETCPTMP.MDB"
       
      ' Make sure the orig does not exist.
      intRet = KillFile_TSB(strDBPath & "NETCPDAT.MDB")
     
      ' Copy the compacted file back
      Call AddLineToLog("Compact Back End - Copying compacted database")
      intRet = CopyFile_TSB(strDBPath & "NETCPTMP.MDB", strDBPath & "NETCPDAT.MDB")
       
      ' NETCPTMP is left on purpose in case of a problem.
       
      Call AddLineToLog("Compact Back End - Compact complete")
   End If
  End If
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.