Delphi writes to the Paradox table only when you say ApplyUpdates, not
before. At that time, it puts the added records into the Paradox table
one at a time. You get to review this process if you want to in
OnUpdateRecord where you get a second chance to fix problems, skip
updates and do other maintenance. OnUpdateRecord is not required,
however.

In your loop, when you say Post you are really posting to the cache,
not to the Paradox table. Cached updates sets up a psuedo-dataset
environment so that you can handle data normally, but only for the
cache. Then on ApplyUpdates, Delphi spins through the cache to repeat
all those things for real on the Paradox table.

Interestingly, the cache is itself a temporary Paradox table that the
BDE creates when you turn cached updates on. The contents of that
table are woven into the current dataset so that when you display the
data, it looks like one seamless dataset.

Phil Cain
--

I am collecting data from an external source. Every five minutes I
want to add to the table. The easiest way is to loop through my
variables, append, define, post. Each post is a disk write. If this
disk operation could be done at one shot it would save disk time.
Something like batchMove or LoadFromFile instead of readln. I gather
from your comments that I do not gain this way, and therefore there
would be no use for me to use cached updates.

records, applyUpdates after the loop, will it write to the disk at the
end of the loop, or for each Post in the loop?

On Fri, 16 Apr 1999 09:13:54 -0400, "Sanford Aranoff"

Yes, cached updates work with local table types. But are you really
describing cached updates or transactions? Which is really what you
need? It sounds more like the latter than the former.

At any rate, *in general*, you would probably be better off applying
cached updates once for the whole group of modifications. To
resynchronize the cache with the base table(s), you need to reopen or
otherwise refresh the cached dataset. To do this after each record
modification would probably be prohibitively expensive in terms of
performance.

//////////////////////////////////////////////////////////////////////////
Steve Koterski                  "The income tax has made liars out of more
Technical Publications          Americans than golf."
Borland                                         -- Will Rogers (1879-1964)
http://www.borland.com/delphi

To repeat my question: Suppose cashedUpdates is false. LocalShare is
true. This way, Post immediately writes to the hard disk. This will
work fine. I was wondering if cashedUpdates would make the disk
process more efficient.
<37176c7c.5376...@forums.inprise.com>...

I agree. Cached updates is best used when you have a business need to
enter a number of records (e.g. an order with one header record and
many detail records) and then update all at once when you're satisfied
that all is correct.

You have the right idea that cached updates can collect changes over
time and then send those changes in a burst to the database, but your
time delays are rather large. You have to weigh the value of that
delay against the need for others to see the data in the database. If
I were gathering one record every five minutes, I'd post directly to
the database and not hold them on the worksstation unless I had an
overriding business reason to do that.

Remember, too, that when you put this data in cached updates, they
reside only on the workstation. Should the workstation lose power,
then the data will be lost.

Phil Cain
--

Hi Phil,

(this should probably be a thread of its own, but hey...)
(and my apologies for the length of this post)

Speaking of cached updates, perhaps you can shed some light
on something for me. I have a few people that are using my
app in a LAN environment, e.g., the database tables are
stored on a server. For direct table access, I've managed
to keep them from stepping on each others toes by locking
the required tables (note: table-level lock, not record-
level lock) prior to writing and releasing the lock after
the Post (this works like a champ).

But...

I have a few grids that are based on rather complex queries
so I'm using cached updates to handle record updates to one
particular table. Apparently, the record locking mechanism
is quite different for queries than it is for tables, and
so I get reports of corrupt indexes from time to time due
to what I presume is some kind of simultaneous access problem.

I'd considered playing some games on ApplyUpdate -- the idea
was to cancel the update (i.e., don't execute the update SQL
statement), and then do the update directly to the table in
code. The problem with that approach is, short of closing and
re-opening the query, there's no way to convey the update
back to the dataset.

So the question is, can I gain a table-level lock when I'm
doing an update query? Local SQL seems to be a bit short-
handed with that kind of functionality, but I'm hoping there's
a way to ensure exclusivity when I'm doing an update via SQL.

Your thoughts would be appreciated!

Thanks...
Chris W.

On Sun, 18 Apr 1999 00:21:53 -0600, "Chris Wallace"

Chris,

As a matter of fact, you can, because of the way how file handles are
recycled in the BDE.

To place a table lock on a table that you're going to update via SQL,
it is enough to open a TTable on the same table (in the same session
and DB) and place a ltWriteLock on it.  This will not lock out the SQL
update because it is going to reuse the open connection on the table,
but it will effectively lock out other users *and* avoid the dreaded
'Too many record locks' error.

Hope this helps,

Jan

On Fri, 16 Apr 1999 16:11:30 GMT, philc...@orelle.com (Philip Cain)
wrote:

Phil,

While I've seen the Del1.MB files with cached updates, I've never seen
a corresponding .DB file.  So I'm wondering if the cache is an
in-memory table with eventual memo fields in the .MB file (as I always
assumed) or is actually a collection of records stored in memo fields
(the .MB file)?

Jan

I'm not sure. I'm fairly certain that the data is not kept solely
in-memory. I was told by an experienced Paradox consultant who likes
to care about these things that the MB files are Paradox or nearly so.
At any rate, they are not intended to be used as Paradox tables.

I do know that the MB files contain information only about rows that
do not match the underlying dataset, that the information is enough to
double-buffer those rows (OldValue/NewValue), that the files contain
information about the kinds of changes made (UpdateKinds), that they
are deleted after CommitUpdates.

I'm in the dark about such things as file layout details and have
never had a need to know more, especially since the VCL doesn't give
any way to directly manipulate the file outside of cached update
methods.

I wish I knew more about what happens to the data when errors happen
during ApplyUpdates, but I've never had any other reason to be curious
about it.

Phil Cain

--

On Mon, 19 Apr 1999 18:55:20 GMT, philc...@orelle.com (Philip Cain)
wrote:

Phil,

This is indeed a dark spot, and we probably shouldn't even care about
the exact representation of the cache.  It's only when you're
interested in performance issues like Sanford was, that this becomes
important.
I'm just too curious I guess... <g>

Regards,

Jan

Hi Jan,

Hmmm -- interesting. I'll have to give it a try and see
what happens. It'd be nice if I could nail this one down
once and for all <g>.

Thanks for the suggestion!
Chris