Roger Engdahl wrote:


Stack overflow is usually caused by an infinite recursion of method-calls;
in other words, an event handler triggers itself before "doDefault" has
been requested.

The type of B-tree record mismatch you report is a statistics-only "error"
that does not justify a repair-process since it will usually fix itself
automatically. (There are two parts: a block number and a record-count.
The record-count is wrong.) This is why CS does not report it if nothing
more-serious does not also exist.

I suspect that the Paradox condition that's causing the stack overflow is
also causing the files not to be updated. It's going to be something in
the error-handling logic, in other words "not the routine path" through the
program.

----------------------------------
Fast automatic table repair at a click of a mouse!
http://www.sundialservices.com/products/chimneysweep

OK ...
I created a new form with a table frame for the item master table and a
second for the inventory transaction log linked in the data model.
There is absolutely no other code on the form.

Problem still exists using the suspect table from the network.
Problem goes away if the suspect table from the network is restructured.
Problem stays away if the restructured suspect table from the network is
moved off the network to a local site.
Problem stays away if the restructured suspect table from the network moved
off the network to a local site is modified, records added etc.
Problem reappears when going back to the restructured suspect table on the
network as soon as it is modified, records added etc.

It is like the stack overflow has to do with trying to figure out which
inventory transaction log record to display, not any explicit code.

Thanks
Roger Engdahl
651 438 5931
612 819 7088
roger.pdxdev (AT) att (DOT) net


"Sundial Services" <info_ns5 (AT) sundialservices (DOT) com> wrote

Roger Engdahl wrote:


How about a non-maintained index in the data model?



----------------------------------
Fast automatic table repair at a click of a mouse!
http://www.sundialservices.com/products/chimneysweep

It sounds like your tables are getting trashed as the result of network
activity. The Citrix servers should be configured as though they were NT
clients, with OpLocks off, Write behind caching off, etc.

--
Larry DiGiovanni
Digico, Inc
IT Consulting and Staffing Solutions
www.digicoinc.com
Check out www.thedbcommunity.com for Paradox resources

Larry DiGiovanni wrote:

It sounds too repeatable, to me, to be that, Larry...


----------------------------------
Fast automatic table repair at a click of a mouse!
http://www.sundialservices.com/products/chimneysweep

Sundial Services wrote:

Maybe, but (a) it should be done nonetheless, and (b) it is consistent
with the behavior Roger is reporting.

--
Larry DiGiovanni
Digico, Inc
IT Consulting and Staffing Solutions
www.digicoinc.com
Check out www.thedbcommunity.com for Paradox resources

Actually, it would be better to do that to the pair of Win2K
file servers mentioned as where the data resides.
================================================== ===========
System Knowledge:
-----------------
I'm assuming that Roger has

ItemMast.db (currently 7000 of)
-----------
ItemID I*
<etc.>


Transactions.db (currently 1.2M of)
Session I*
Sequence I*
<etc.>
TimeStamp @ (v)
ItemID I (^)

Problem:
--------
"Once a users passed a point in the ItemMast table they would
get a Stack Overflow error and the pdox session would terminate.
There is no explicit code that happens between these tables as
the user moves from one record to the next in the inventory
table."

Errors triggered by simply moving from one record to the next
are usually caused by missing or bad inter-block pointers within
the Paradox table. However, it is not usual for Pdx to just
terminate as a result !

"If I restructure the Transaction table, the form works fine
until the next transaction is added. "

That is, until the next record posts into the table. Then some
problem damages the table again.

" I have noticed on the Win2K file server that the
Transaction table, the primary key and secondary key file
date/times have varied by as much as 22 minutes. I would expect
them to be virtually the same."

I would have expected them to be close, too, as you imply that
almost all accesses to this table are for writing new records.
However, if you don't explicitly issue a "postRecord() when you
finish your code to add a new record, you might get the
situation where Paradox itself is caching the data.

Finally, I am surprised that the problem is triggered when
traversing the ItemMast table ... unless you are doing it on a
form with the Transactions table attached. In which case, are
you doing anything on the form that displays the Transactions
that would actually cause a transaction to occur ?

Mike


In article <bdc9dv$qubqk$1 (AT) ID-129771 (DOT) news.dfncis.de>,
larryd (AT) digicoinc (DOT) com says...

Mike ...

Structure assumption is correct.

There are four processes where transactions records are logged. I checked
then all. postrecord() then unlockrecord() are called in every case.

In the original form and in the test form the Item mast table is the parent
and the transaction log is linked using its secondary index comprised of the
ItemID and the timestamp(D). In both cases the transaction log is readonly.
Nothing is ever done to the transaction log from this form.



"Mike Irwin [CTech]" <mirwin (AT) paradoxcommunity (DOT) com> wrote