Very Computer

by **Roger Engdah** » Tue, 24 Jun 2003 23:27:50

Oh, Wise Ones!

I have a table with inventory items keyed by the itemID (longint) (7000
records) and another table with inventory transactions keyed by a unique
session and sequence pair of long integers (1.2 million records). The
transaction table also has a secondary index on the itemID and a timestamp
field (descending). Both tables 32k blocks. (Table size about 83 Mbytes,
secondary index file sizes about 30 Mbytes)

P7/32 with update 4, 3-Win2K clustered servers running Citrix with 30 - 60
users writing to one or more clustered Win 2K file servers.

Worked for months without complaint until last week. No changes to the form
or the tables (other than growing larger). 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.

If I restructure the Transaction table, the form works fine until the next
transaction is added. 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. Network wonks claim writeback caching is disabled.

Chimney Sweep reports no problems with the table.
TableRepair indicates the table needs repair w/o any reason showing but
error 53, level 2 "Btree record mismatch Block 1, record 9 to block 10" but
the form still works.
without repair, Chimney Sweep still reports no problems with the table.

Any ideas appreciated as always.
Thanks.
--
Roger Engdahl

by **Sundial Service** » Tue, 24 Jun 2003 23:42:16

> Oh, Wise Ones!

> I have a table with inventory items keyed by the itemID (longint) (7000
> records) and another table with inventory transactions keyed by a unique
> session and sequence pair of long integers (1.2 million records). The
> transaction table also has a secondary index on the itemID and a timestamp
> field (descending). Both tables 32k blocks. (Table size about 83 Mbytes,
> secondary index file sizes about 30 Mbytes)

> P7/32 with update 4, 3-Win2K clustered servers running Citrix with 30 - 60
> users writing to one or more clustered Win 2K file servers.

> Worked for months without complaint until last week. No changes to the
> form
> or the tables (other than growing larger). 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.

> If I restructure the Transaction table, the form works fine until the next
> transaction is added. 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. Network wonks claim writeback caching is disabled.

> Chimney Sweep reports no problems with the table.
> TableRepair indicates the table needs repair w/o any reason showing but
> error 53, level 2 "Btree record mismatch Block 1, record 9 to block 10"
> but the form still works.
> without repair, Chimney Sweep still reports no problems with the table.

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

by **Roger Engdah** » Thu, 26 Jun 2003 00:30:47

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

> > Oh, Wise Ones!

> > I have a table with inventory items keyed by the itemID (longint) (7000
> > records) and another table with inventory transactions keyed by a unique
> > session and sequence pair of long integers (1.2 million records). The
> > transaction table also has a secondary index on the itemID and a
timestamp
> > field (descending). Both tables 32k blocks. (Table size about 83 Mbytes,
> > secondary index file sizes about 30 Mbytes)

> > P7/32 with update 4, 3-Win2K clustered servers running Citrix with 30 -
60
> > users writing to one or more clustered Win 2K file servers.

> > Worked for months without complaint until last week. No changes to the
> > form
> > or the tables (other than growing larger). 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.

> > If I restructure the Transaction table, the form works fine until the
next
> > transaction is added. 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. Network wonks claim writeback caching is disabled.

> > Chimney Sweep reports no problems with the table.
> > TableRepair indicates the table needs repair w/o any reason showing but
> > error 53, level 2 "Btree record mismatch Block 1, record 9 to block 10"
> > but the form still works.
> > without repair, Chimney Sweep still reports no problems with the table.

> 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

by **Sundial Service** » Thu, 26 Jun 2003 01:06:21

> 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.

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

by **Larry DiGiovann** » Thu, 26 Jun 2003 01:46:36

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

by **Sundial Service** » Thu, 26 Jun 2003 05:07:44

> 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.

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

by **Larry DiGiovann** » Thu, 26 Jun 2003 22:46:37

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

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

by **Mike Irwin [CTech** » Fri, 27 Jun 2003 02:40:29

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.>

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

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

> 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

by **Roger Engdah** » Fri, 27 Jun 2003 11:50:36

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.

> 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.>

> 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

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

> > 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