DBC Too Large

[JICGreg]

I'm receiving an error message that my dbc is too large. The help feature says it cannot be over 2gb, and according to windows explorer it is (explorer says the file is 2.097gb).

This is part of a project that is run on a monthly basis and has been running fine up until this month.

I have deleted every table that is not absolutely necessary. This has been probably 50-60 tables. Surprisingly, there has not been any change in the size of the dbc file (explorer still lists it at 2.097gb). I have opened the database and done a validate database which comes back with no errors and a valid database container.

What else is included in a dbc besides tables (I'm assuming tables are included but b/c of no change in the dbc file I'm beginning to wonder)?

Any input/ideas would be greatly appreciated.

 

[markros]

Try opening DBC as a table and pack it, e.g.

use myDBC.DBC exclusive
PACK

The views are also included into DBC container.

 

[JRB-Bldr]

If your files are already pushing or over the VFP 2GB file size, you are pushing your luck already.

Do all of those tables HAVE to be contained WITHIN the single database?

Can some (or all) of the tables be FREE and not within the database?

Or can some of the tables be moved into a 2nd VFP database?

If you do reduce the size of the database in some manner, another way to compress things is to use the database designer tool in the VFP development environment.

SET EXCLUSIVE ON
MODIFY DATABASE MyDBC

* --- from the top menu ---
* --- choose [B]Database | Clean Up Database[/B] ---

CLOSE DATABASE
SET EXCLUSIVE OFF

Good Luck,
JRB-Bldr

 

[Mike Lewis]

JICGreg,

The size of the DBC file is not related to the sizes of the tables. The DBC is a separate file, which contains only meta data. Deleting tables will not alter the size of the file.

Frankly, I'm surprised that your DBC is anywhere near as large as you say. Are you sure you are looking at a DBC file, not a DBF? In my largest application, the live DBC is less than 1 MB.

If the DBC really is that big, you should first do what Jrbbldr and Markros suggested: either pack it, or "clean it up" (which does the same as packing it).

That should solve the problem. If it doesn't, I would think something is seriously wrong with the DBC, and it would need some careful examination.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[cbasoz]

That happens if you frequently add/delete objects to dbc at runtime (such as create view/drop view, index and delete indexes). Normally a dbc is created during design time and from there on its size is fixed and small. Pack memo/Pack are temporary bandages to your problem. Find and fix in your application code those that add/delete objects to DBC at runtime.

PS: (Instead of packing you might simply copy dbc files from a backup, it is metadata only).

Cetin Basoz
MS Foxpro MVP, MCP

 

[JICGreg]

Thank you for your counsel. Your suggestions fixed the problem.

 

[Olaf Doschke]

Seems like you did a lot of creating new tables, perhaps temp tables only, you DROP in the end of your processing, eg you do SELECT ... INTO TABLE xyz etc, then finally DROP xyz. This creates new records in the DBC file, which indeed also is a DBF Format file, it's a table you can also USE (if it's not over 2GB). And as in a DBF there are operations adding records ( here SELECT INTO TABLE or CREATE TABLE, INDEX etc) and operations deleting records (eg DROP TABLE), but as in a DBF deleted records are only marked for deletion and not removed unless you PACK the DBC.

The best thing is to avoid such operations in a DBC, use CURSORS instead of tables. There's no need to make temporary things available in a DBC, especially if a single process is crunching on data this can all be done in cursors.

A DBC is normally created once and stays quite the same unless there are structural DBC changes needed for new features for example.

If you really want to create tables in your processing instead of cursors, to have something on disc if the process fails half the way, simply CREATE a new temporary DATABASE to do such DBC modifying things in there.

Save that grown DBC and shrink it to 2GB with this tool:

http://code.msdn.microsoft.com/FoxPro/Release/ProjectReleases.aspx?ReleaseId=126

Afterwards USE it as a table and see what's inside, especially with SET DELTED OFF see what records are in there marked for deletion. I assume that are rows belonging to tables and perhaps also indexes, which were created and dropped over and over again every day.

Bye, Olaf.