nextrecord table not being updated
Phil Marcus
There is a hoary old technique for automatic numbering of records that uses
a 1-column, 1-record table to store the next number. I am using such a
technique in a multi-user app (Win2K server, mostly Win2K desks but a few
Win98). Problem is the table is not always updated by the code that is
supposed to (with disastrous results of course). It acts like the cached
copy gets incremented, but somehow that data never gets written back to the
server, at least not consistently. Any ideas? Does it matter whether the
tcursor that does the updating does a .postrecord or .unlockrecord after the
increment step, for example?
Phil
Mark Bannister
The tcursor should use unlockrecord. Postrecord is superfluous.
Sounds more like a disk chache problem. Most database apps need disk
caching disabled.
Mark B.
Steve Caple
Phil Marcus wrote:
> There is a hoary old technique for automatic numbering of records that uses
> a 1-column, 1-record table to store the next number. I am using such a
> technique in a multi-user app (Win2K server, mostly Win2K desks but a few
> Win98).
Only one column? OK for only one table, I guess, but usually there's a
table name column and a key value column.
> Problem is the table is not always updated by the code that is supposed
> to (with disastrous results of course). It acts like the cached copy
> gets incremented, but somehow that data never gets written back to the
> server, at least not consistently.
As Mark mentioned, you need to have all write-behind caching and such
Windows phurphey turned off. I believe there's an entry in the cnews FAQ
group on this.
> Any ideas? Does it matter whether the tcursor that does the updating
> does a .postrecord or .unlockrecord after the increment step, for
> example?
Yep, unlockRecord()
--
Steve Caple
SeatTech
Tony McGuire
Besides write cache, you should disable opLocks on the computer that hosts
the auto-numbering table.
--
Tony McGuire
Tom Krieg
I've seen behaviour like this (and it was discussed some time ago) when
a tcursor is open for a while. Updates made by other users are not
visible to the open tcursor until a forcerefresh() is issued. The
tcursor cache is also refreshed on switchindex or setrange.
Tom krieg
Steve Caple
Tom Krieg wrote:
> I've seen behaviour like this (and it was discussed some time ago) when
> a tcursor is open for a while.
Wouldn't the tCursor on the control table be opened and closed with each ID
generation?
--
Steve Caple
SeatTech
Tom Krieg
Don't know, he doesn't say. Just wanted to mention it. Pdox seems to
buffer tcursors and not refresh them. In some of my apps, I open
tcursors when a library opens and do all my tcursor processing in
library methods. The library stays open while the user is in the app.
Saves the overhead of opening tcursors hundreds of times. There appears
to be little overhead in forcerefresh(). I just call forcerefresh() at
the start of tcursor code to ensure I have the latest view of the table.
Tom Krieg
Steve Caple
Tom Krieg wrote:
> Saves the overhead of opening tcursors hundreds of times.
I haven't found that to be a significant factor; I just do what I need to
with the tCursor and close it before returning. In some cases with
multiple tCursors that requires a little extra code to close, say, the
first two when the third open fails or such, but it's no big deal.
--
Steve Caple
SeatTech
Mark Bannister
I did a little experiment with opening TC's verses leaving them open and
using forcerefresh. The latter is MUCH faster (after the first open of
course). I use an array of TC's in a library and keep them open for a
set amount of time. To pass back and forth I use attach in a library
method.
Dennis Santoro
Certainly should be...
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits since
1982
Dennis Santoro
Maybe true for large tables. I sometimes leave tc's open for the whole time a
specific form or library is open. But with a control table for keys, you would
have to have a HUGE number of tables under control before it would make a
noticeable difference (I don't think I have ever had more than 300 under control
of one control table) and the fact that when you open the tc it WILL have the
current table records in it is more important than any lost nanoseconds.
Tom Krieg
Denn,
I agree. But sometimes, especially when generating large numbers of
records for a process (e.g. when creating a keyed table from, say, a
transaction file) it's more efficient to leave the keys table open than
to keep opening and closing it 1000 times in sequence. But that's a
special case. I just made an observation that this is what may be
happening **if** he left the keys table open for a while.
Tom K
Mark Bannister
Dennis:
A forcerefresh takes care of any problems with the current table
records, that's a not an issue.
I have found though that it does save a good bit of time, not only with
larger tables. One reason is that very often the user is working with
the same groups of data, so instead of repeatedly opening and closing a
table and re-locating the same record, the table stays open for 10
minutes or so and stays on the current record.
I initially used this approach for commonly opened tables, company,
employee, etc, but now I seldom discriminate. If a user is working with
forms these tables are usually open in the form anyway. (In fact as I've
mentioned before I don't link 1-1 relationships in the datamodel anymore
but use this same library to display 1-1 link info.) This method also
tidies up code nicely. This call:
mylib.tcattach(stTableName,mytc,liID), opens table stTableName if it is
not already open, attaches mytc to it, and locates the key field LiID
(if the table is not already pointing to it). This centralizes error
processing as well. I use 5-6 other common methods that return arrays,
locate on secondary indexes, or change the current record. The next
most common ones I use are tcGetArray(stTableName,myar,liID) and
tcWriteArray(stTableName,myar,liID).
This method has many advantages independent of how many tables are
staying open. After about a year of use I have had no problems with
table corruption or tables remaining locked. It appears to be as stable
as having forms open.