PDA

View Full Version : Missing Memo Fields


ABC123

Linda Fasoli
12-28-2001, 08:12 AM
We were running V6 on a Windows 2000 network (not knowing that they were incompatible). My memo fields became corrupt - they were no longer pointing to the .dbt files. I installed V7, deleted the offending memo fields, created new memo fields and thought that we were in business. Now I am finding that the information in these brand new memo fields is disappearing. It's there one day, gone the next. This is exactly the same problem we were having when we were told that the field was corrupted by running the database on Windows 2000. I haven't heard of this happening to anyone else - is my database completely corrupt or is this a problem in V7? Any ideas?

Tom Cone Jr
12-28-2001, 06:22 PM
Linda,

How many copies of your database files, especially the dbt memo files, are present in your complete network? i.e. the server and each workstation.

I ask because your description causes me to wonder if the users are updating one copy, perhaps locally, and then later, the next day for example, logging in to a different copy, perhaps on the server.

-- tom

Linda Fasoli
12-30-2001, 09:05 AM
Tom,

All the data is on the server. Each workstation has the program installed on it, but nobody has the data on their workstation.

Linda

Tom Cone Jr
12-30-2001, 11:05 AM
Linda,

Look for things that might cause the memo field to get out of synch with the main database.

As you know memo fields are stored in separate dbt files. when you begin a new record in your database the memo field is not created in the dbt file until the dbf record is saved. Might something be interrupting this in mid-stream?

Here some things to consider:

1) change your procedures. When you need to enter a new record, enter it, then save it immediately. Then change it, and save the changes. This should force the memo field to disk, I should think.

2) is it possible someone in your group is deleting memo field values without realizing it... or worse, on purpose?

3) is it possible someone is restoring the dbt file using an out of date backup?

4) slow down the data entry, and carefully check the memo field values, between new records. After a new record is entered and saved. Can anyone else on the network see it? They should be able to see the new memo field, of course. If they cannot that may mean that while you think all the data is on the server, someone is updating local tables.

-- tom

Linda Fasoli
12-30-2001, 04:47 PM
Tom,

Thanks for your suggestions. I really suspect that this problem is somehow related to the fact that we upgraded to a Windows 2000 server. Nothing except that changed, and that's when the problems started. I was told by Tech Support that this may be data corruption that may have happened since we were still using version 6 (which is why I quickly upgraded to version 7). Supposedly, upgrading to version 7, deleting the memo field and adding a brand new memo field was going to fix the problem, except I see that it's happening agan.

It seems to happen every few days. I looked at some of our backups and the memo fields are OK for a few days, and then the data suddenly disappears. Nobody fools with the files, the backups, or the database (except to enter new data) except me. They save the files as soon as they're entered or changed. The only thing that I can think of that happens every few days is that the database gets re-indexed. I have a little backup application that they run every morning that packs the database and then backs it up. Since they don't mark records for deletion every day (and if there's nothing to delete the re-indexing doesn't happen) I'm thinking that this may be when the memo data gets deleted. That's the only type of file maintenance that happens on a regular basis.

I haven't a clue what's going on - I added a new "memo" field - it's actually a long character field - and told everyone to use that field for notes for the time being.

I'm seriously considering returning this version and going back to Windows 98 on the server. In addition, to this problem, I'm having a horrible time with the printer drivers. That's another problem for another day, though.

Thanks for your help. Please let me know if you think of anything else.

Linda

Tom Cone Jr
12-30-2001, 11:48 PM
Linda,

Is there any possible way another user would ever have a chance to delete and re-enter a record in your DBF? If this happened, the link to the memo field in the DBT would be broken.

Have you verified that when you enter a new record, including memo field text, that it's visible at other workstations?

I think it's possible you misunderstood my earlier suggestion. I would design the data entry routines so that no one ever spends time filling in the fields while a new record is pending. If a new record is needed, I would create it and then immediately save the empty record to disk... especially if I were using an autoincrement field rule to distinguish my records. Then I'd immediately continue edits using 'change' rather than 'enter'.

-- tom

Linda Fasoli
01-02-2002, 12:25 PM
Tom,

Thanks so much for your help here. I'm confused - you mean if someone deletes a record and then re-enters that data into a new record the DBT file breaks? That doesn't make sense. All the users have the ability to mark a record for deletion. I sure hope I'm misunderstanding here, because how else do you delete records? Plus, this problem only started happening when we changed servers, and people were deleting records way before that with no problem.

As far as seeing the record on another workstation - yeah, I tried that and the record (and memo data) appear on the other workstations.

When the users enter data, they're usually on the phone with the person and filling in the data as they're talking - the chance that somebody else would try to access a new record is pretty slim. Nobody knows that the record exists until the record is saved.

The memo fields never come into play until the record's been in the database for sixty days (it's a collection field). When the memo information disappears, it doesn't just happen to one record, it happens to them all!

This is what our computer geek suggested - he said to copy the database to a local drive running on Windows 98 and just do what we normally do. See if I can "make" the database erase the memo fields. What do you think?

Thanks again for your help.

Linda

Tom Cone Jr
01-02-2002, 11:34 PM
Sorry about the confusion.

I meant simply that if a second user deletes a record from your database and then re-enters a record in the same position (using the same index key value) the original memo field text will be lost. Your problem sounds different.


Since you're not losing the text from the memo field on isolated records... you say you're losing all the memo field text in all records at one time... I think this sounds like a problem managing the dbf and dbt files themselves. Have you looked at the DBT file to see whether it's truly empty ( i.e. zero bytes long) ?

Another wild idea:
If you move the dbf and ndx files to another drive or folder, and begin using it, I think Alpha Four will create the dbt for you. If this is right, it will be created empty, of course. Could something like this have happened?

Yet another crazy question:
If your dbf and dbt files were in one folder, and you backup the dbf (but not the dbt) files to a second folder... what would happen if a restore from the second folder occurred? You'd wind up with a current dbf, but the dbt would be empty since it was never backed up. Could something like this be going on?


If possible, you might benefit from reorganizing your table structure. Instead of using a memo field in the same database as the rest of your data, you could create a second database, just for the memo field text, including a second field to be used to link back to your main database. Then create a set using a one to one link between the main database and the new table. Once the second table is populated with linking keyfield values and the existing memo field text, you'd drop the memo field from the main database entirely.


-- tom