Generally speaking, any dBase compatible system (for example,
CodeBase,
http://www.sequiter.com/) will tend to be faster
than Jet. This is for three reasons: 1) Each table and index
is a separate file. This means that when you really want to
deal with just one table, the file is smaller. 2) The records
are fixed length. 3) The system only uses direct locking,
instead of opening a lock file.
But if you want top performance, why are you using OLEDB?
In any case, you need to sort out your indexing and your
bloating.
And of course you need to review your database actions,
just to be sure that you aren't accidentally doing anything
like connecting in shared mode to a full-table recordset
every time you want to do an append :~)
(david)
PS - please post back and let us know how you get on :~)
"Riley DeWiley" <riley.dewiley@gmail.com> wrote in message
news:10od0ld8lhiqqa5@corp.supernews.com...[color=blue]
> The big problem is in inserting into a junction table, J, that joins two
> other tables A and B.
> I enforce referential integrity through the join from both sides. I don't
> really need to. Will I save a lot of perf by turning it off?
>
> When the junction table approaches about 1 million records, the act of
> inserting a new record into it seems to take almost 0.25 - 0.50 seconds[/color]
per[color=blue]
> record.
>
> I have previously noticed massive size bloat with this database, which I[/color]
cut[color=blue]
> down at runtime with frequent compact+repair operations. By "massive" I[/color]
mean[color=blue]
> the database grows to 1.5 gig, after compaction, it is about 40 megs.
>
> Must go but will send more info later as needed.
>
> Thanks to all for assistance.
>
> RDeW
>
>
> "Nick Landsberg" <SPAMhukolauTRAP@SPAMworldnetTRAP.att.net> wrote in[/color]
message[color=blue]
> news:00uhd.52787$OD2.7783@bgtnsc05-news.ops.worldnet.att.net...[color=green]
> > Riley DeWiley wrote:
> >[color=darkred]
> > > I am developing in c++, OLEDB, and targeting the Jet backend. I have
> > > realized late in the project that the Jet backend is too slow, and I[/color][/color]
> need to[color=green][color=darkred]
> > > retarget. I do not want to rewrite my source code. I do not want to[/color][/color][/color]
pay[color=blue][color=green][color=darkred]
> > > royalties. I want better performance. The application is single user,[/color][/color]
> local[color=green][color=darkred]
> > > access only, but needs high performance. Fancy features are not[/color][/color][/color]
required[color=blue]
> in[color=green][color=darkred]
> > > general ...
> > >
> > > Can anyone recommend a new backend?
> > >
> > > RDeW
> > >
> > >[/color]
> >
> > To add to what others have mentioned ...
> >
> > Some questions:
> >
> > What performance is required? What is it today?
> > (Specific numbers, not just "it seems slower than
> > it should be.")
> >
> > First approximation: do you have the appropriate
> > indices set?
> >
> > Second approximation:
> >
> > In my experience, perceived performance problems
> > are hardly ever due to any back-end DBMS, but are
> > probably due to the access code doing something
> > "unwise." For example:
> >
> > - An application which issued 44 queries to populate
> > 44 fields on a screen.
> > - Another application which queried the meta-data
> > to find out the field names and attributes and then
> > formulated the SQL on the fly to query for the
> > values.
> >
> > --
> > "It is impossible to make anything foolproof
> > because fools are so ingenious"
> > - A. Bloch[/color]
>
>[/color]
