Re: Acc2000 Database Bloat, Compacting doesn't resolve issue

"TLS" <tim.sexton@xxxxxxxxxxx> wrote in message
> Can anyone provide some insight on preventing Access database bloat? I
> am currently developing a VB6 application that uses ADO to interface
> with an Access 2000 db, retrieve SQL statements stored in a table,
> execute those SQL strings, publish the query results in Excel, update
> status tables and output a notification report from Access 2000.
> My Acc2000 development db has ballooned from 1 meg to over 300 meg and
> compacting the database does not significantly reduce its size.
> I don't know if its pertinent to the issue but the Acc2000 db has
> several linked tables(Sybase,Oracle and Access)

I hope I am wrong, but AFAIK it is the nature of the beast.

It will grow even larger during run-time. You didn't mention how many
reports, queries, VBA, etc. you have, but you can occasionally reduce the
impact by employing various strategies to split the table objects from the
other stuff. Look up ADP, MOD, and Database Splitting in the MSAccess Help.



Relevant Pages

  • Re: Beginning C# Q
    ... starting out with a network app0lication, you have an awful lot to swallow. ... Designing your database is therefore, not quite the first step, particularly ... Groups table, which defines which Groups users belong to, and a Permissions ... That is why an Interface is called an Interface. ...
  • Re: Transaction Oriented Architecture (TOA)
    ... If one builds the application around the database view, ... The problem solution should not have to know about mechanisms like SQL query construction, optimizations like anticipatory caches, or encoding/decoding of dataset formats. ... Note that the CRUD/USER environments already provide exactly that encapsulation by providing a Data Layer that is isolated from the rest of the application through an interface. ... TOA/TOP proposes the database and its application domain stored procedures are the only persistence mechanism necessary, and that the benefits of a focused, single, data-permeable gateway between application and database far exceed the benefits of O/R mappings--regardless of abstraction--and that its lightweight appearance shouldn't be dismissed as missing heavyweight kick. ...
  • Re: Transaction Oriented Architecture (TOA)
    ... I don't think the issue is ignoring the database; it is recognizing that the database is a different subject matter applying different business rules than the problem solution. ... There is nothing to prevent abstracting the database subject matter in a classic OO manner with objects like Schema, Table, Tuple, and Query. ... I'm of the opinion that the more obvious the database (or at least its interface) is the more easily maintainable an application becomes. ... I've nothing against creating frameworks and patterns to facilitate those programming activities, but prefer the concept of a problem domain transaction to language-specific expressions mapping 1:1 with anything physically present in the database. ...
  • Re: OOP style
    ... Component classes have all their main logic in a Custom base class ... database access unit if they didn't already start with a full DB layer; ... My latest application started with an extensively designed object model ... Typing in the implementation of the database interface is ...
  • Re: OOP/OOD Philosophy
    ... You appear to assume that, in order to isolate the database from the gui, ... the GUI layer uses a specific interface of the business ... This is where you need to place logic against the data structure that ...