File Update Problem

[Becky McNichols]

I recently went out an app update which contained several *.ddd, *.ddm, *.ddx, *.sem, *.sex, *.sex files (no *.dbf, *.cdx, *.fpt files). The new files were copied directly over the old ones in the user's "application" directory (all use Runtime version).

After the updates were installed and database compacted, some users had trouble with auto-increment fields resetting back to a previous number instead of going on in consecutive order. For example, if a user was ready for salesform #545 before the update, a new salesform came up with #530 (an existing salesform number) after the update was installed. Of couse, this has caused a lot of reporting and lookup problems.

These were all character fields defined in field rules as auto-increment.

Has anyone else had this happen? If so, WHY does it occur? How can I handle future updates to avoid this problem?? Thanks.

[Tom Cone Jr]

RE: File Update Problem

Becky, the term 'application directory' is not clear to me.

When I do an update such as you describe, I store the new files in the 'database' directory on the server, and then refresh the shadow files on each workstation, or network optimize each workstation to bring them up to date. Shadowed copies of the files you updated will not automatically be updated just by copying new 'originals' into the database folder on the server.

The autoincrement field rule is not bulletproof. If two data entry people start a new record in quick succession, they can wind up with the same number, since the field rule calculates it at the beginning of data entry for each pending record. The second user's system has no way to know whether others are also working on a new record which has not yet been saved.

If the 'wrong' autoincrement value is significantly different from the actual value in the last record of the table, I'd check to make sure that the runtime version is not working with an incorrect copy of the database. I've heard of situations where the runtime user thought they were working with data on the server, but were in reality working with a duplicate set of tables inadvertantly copied to the local workstation. Such a bizarre thing could account for different values in the 'last' physical record of the table. Remember, it's the value in the last 'physical' record that is used by the autoincrmeent field rule.

-- tom

[Valerie J. Breitbach]

RE: File Update Problem

I have a very similar situation, and I just found out about it today.

I had a problem with autoincrement about 4 months ago and with help from the message board, I tracked this first one down: I had 'shut off' the auto-increment field rule to fix some problems. When I turned it back on, I wasn't at the end.

At that time I stored away the 'use an algorithm' thought, but hadn't touched it. Well today, the client called and let me know they have duplicate #'s again.

But my problem this time seems similar to yours. I sent some updates last week, and now this autoincrement thing cropped up again. My whole app resides on the server, and for almost a year, when I change or add forms, I send all the changed files except the *.fpt, *.dbf, *.cdx. They overwrite the other stuff, and upgrades occur. But now, I have this other problem creeping up.

Any ideas?

[Valerie J. Breitbach]

RE: File Update Problem

One more note -- the dups didn't occur in two 'new' accounts, but a new account duped a number that was 6 months old.

[Tom Cone Jr]

RE: File Update Problem

Valerie, I'm alarmed at your report (and Becky's) since your approach is what I do, too, except I don't routinely compact the database. I suggest you have the client send you the data files so you can test them completely. Is it possible they've somehow truncated the file, or corrupted it somehow?

--tom

[Becky McNichols]

RE: File Update Problem

I use Wyse Installmaker which was packaged with my Professional Version of Alpha5 Runtime. When my app is installed on another computer, it puts my program name ("weedwyse") under Program Files and creates 2 subdirectories: runtime (contains runtime files) and application (contains the app files). This is what I mean by "application directory".

All of the people using this are on standalone PC's - no networks. They have a utility built into the app where they can compact the database themselves after new files have been added or formats changed.

[Peter.Wayne]

RE: File Update Problem

i suspect the problem occurred, not from the update, but
from the compaction of the database. possibly for some
reason the compaction of some of the tables failed. how
do your clients perform compaction? do they have access
to the control panel? did they see any errors during
the database compacting? have they ever compacted before?

[Valerie J. Breitbach]

RE: File Update Problem

Today, my thoughts are even fuzzier, but if the dups are all new accounts since Thursday, I may have a clue. I created a new set at my machine, and then loaded parts. When I got to their network to test it, it didn't work. After some head scratching, I realized that my new set had created a new index, an index on one of the tables. But I don't copy *.cdx. So I created that index at their machine. Could that have caused an auto-increment problem?

It was on a different table than the one with the auto-increment problem, but the auto field is on the parent table, and the new index was on the grandchild.

I'm testing at their site later today.

[csda1]

RE: File Update Problem

Tom,

The autoincrement field rule is not bulletproof. If two data entry people start a new record in quick succession, they can wind up with the same number, since the field rule calculates it at the beginning of data entry for each pending record. The second user's system has no way to know whether others are also working on a new record which has not yet been saved.

That's only partially correct. Add the time of the save, the autoincrement rule rechecks to see if that value has already been saved and then increments the number by one if it does. Any fields based upon the autoincrement field are also updated. It is possible to have rules that the autoincrement can not update though.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[csda1]

RE: File Update Problem

Valerie et al,

When you copy just the data dictionaries, the assumption is that you have not changed the structure or index names. If you have changed the structure (e.g. deleted fields, moved them around, renamed them) some layouts may fail due to referenced fields. The index part of the data dictionary may also have problems.

Index definitions are stored primarily in the index, but another part is stored in the dictionaries. Having index names 10 or less in length are safer as the longer versions are stored in the data dictionaries. Shorter ones can be stored in the index and are the ones A5 defaults to if the data dictionaries have a problem. If the index file definitions is changed in any way, it behooves you to send the cdx file as well. This can be based upon an empty table (which makes it a lot smaller). After you have copied your updated dictionaries and cdx files, then do a reindex (or a compact that will also do a reindex) before using the new ones.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[Becky McNichols]

RE: File Update Problem

The users do not have access to the control panel. I have a button in a utility menu with a system maintenance script attached. This script was provided to me by Finian Lennon ("DBCompact" -I think I've seen it elsewhere on this site). After compacting, it allows the user to run a file maintenance report to see if any tables failed. To my knowledge, none failed.

[Tom Cone Jr]

RE: File Update Problem

Ira, thanks. I didn't know that. -- tom