Zugg Software :: View topic - database bug: first field gets overwritten

Beginner Joined: 24 Feb 2005 Posts: 27

I couldn't find a bug list forum, and my membership to the beta group is still pending, so I thought I'd post this here.

I'm still working on a fixed set of steps that will duplicate this problem consistently, but I've seen it often enough now that I thought I'd mention it. I run version 7.13b on Windows 2000 Pro.

What happens is that sometimes, the first field of the active view gets overwritten with "random" data. By "random", I mean that the field will get populated with data from a previously active field. For instance, if the first field contains, say, an item's Name, and the second field contains the item's Type, the value for the Type gets copied into the item's Name.

I see this most often when I'm creating or modifying new Views of a database. It seems exacerbated by attempts to use #FIND against a View that is not currently active, but again, I do not have a set of steps to duplicate it consistently yet.

I mention it here in case anyone else is running into this and knows what is going on.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have seen something similar before. Using #DBRESET after finds and queries cleared it up so that I have never seen it again.

Beginner Joined: 24 Feb 2005 Posts: 27

I'll have to check if #DBR fixes the issue, the next time it occurs. I know switching between records auto-saves the data, at which point it is too late and must be fixed by hand.

I'm still working on steps to duplicate the issue consistently.

Beginner Joined: 24 Feb 2005 Posts: 27

Okay, so, here's the latest. For the record, I'm on version 7.20b (the upgrade went very smoothly, btw).

Other than the implicit find/query that occurs from having a new view, I am running no queries, so I'm not sure what #DBR will get me. Today, I created a new view on the data that would sort by the Zone for the equipment. And I moved the Zone up to be the first field that displays. If I try and use this View to view data, it will overwrite the zone value for any record I select....any one at all. So if I were to click through all my records, I would rapidly blank out all the data. And the kicker is, I can't re-edit the data while I'm using this particular view, since once I switch to another record, the Zone will blank out again.

I initially thought this was just an artifact to toggling between the List screen and the Record screen (the List screen, by the way, shouldn't allow editing of any kind, in my opinion). But when I just used the Record screen, the problem was still there.

This is not good. The database is not highly useful unless you can search through it, and static views shouldn't overwrite the data. And at this point, I have no way of knowing how much data I've lost, which doesn't leave me too thrilled.

Is no one else running into this problem?

Apprentice Joined: 20 Sep 2005 Posts: 135

I've seen it too. I'm using the eq db template. If I'm manually scrolling through the records and tab through either of the any number fields I've crated, their numeric values get copied into the Name field for that record. I have to go back and manually input the name again, if I can remember it.

E.g., very disturbing to see something like "a wooden ring engraved with a flying hawk symbol" being written over to "12".

Apprentice Joined: 20 Sep 2005 Posts: 135

On all my Views I unchecked "AutoAppend" and the overwriting has stopped.

Newbie Joined: 27 Sep 2005 Posts: 5

I got the same issue. Unchecking AutoAppend doesnt help - each time update of any record field is done, value of Name field is overwritten. Im my case the new value is 0. Only idea I have is that it happens because I added new field to my database, but I really do not understand why it happens... And then what Im supposed to do? Abandon current database? Not a real solution I guess...
Earlier locking view helped to prevent change of value when browsing DB(seems that it still helps).
But, now I got this problem when with help of script I want to change any value within DB... And that happens even when query is run! In such cases almost all item names becames 0! And that hurts since now Im unable to use it at all - checking DB after each 5 min, making back-ups of it, restoring, etc, etc, makes no fun at all.
I must say that this problem exists in all zMUD versions since DB module was introduced. And, of course, that means that DB module always has been very unreliable. When new version of zMUD comes out I allways hope that now it will be fixed, but nope...
I wonder how other guys who builds their equipment databases have managed to avoid it...

Also, maybe someone smart can make suggestions(read, share code) how to use external database (f.i. MS Access)? For me it seems to be the only way how to be sure that data you have stored will not be lost...

Apprentice Joined: 20 Sep 2005 Posts: 135

Well, the AutoAppend trick stopped working for me :(
I'm using the default eq template. The default Name field is overwritten by info from any new fields I've created whenever they are manually accessed (tab, arrow, or click in the field). Is there some kind of bug that new fields are incompaitble with the default fields? I suppose I should try creating a db from sractch, or deleting all the default fields, and migrate the info to see if that clears the problems.

Newbie Joined: 27 Sep 2005 Posts: 5

I tried to solve this problem by adding additional column right before Name column.
I was surprised since even weirder thing happened - this column started to act like mirror of Name column!
I mean at first it got all the same values as Name column, and later on, when the problem I was looking for still persisted, those columns(fields) where changing their values simultaneuosly - new column acted like mirror of Name column. For instance, if item name changed to 0, the proper field of new column did the same. If I changed manually the name of item, new columns' field got the same value...
To be honest now Im completely lost, have no idea what can be done next to try and to cheat this, IMHO, bug.
Any suggestions?

Yes, unchecking autoappend, locking or unlocking view do not help, making field internal also have no effect...

Newbie Joined: 27 Sep 2005 Posts: 5

Ok, I worked out one solution which seems to work for time being. Since luckily I had not corrupted DB copy (it was unusable for any data changes but at least it contained correct data) I decided to try to re-build it.
However, I was lazy and decided to write script which would copy data from old DB to new one.

So here comes how that can be done:
1st step - Copy all data to variables
That can be done with following script:
#DBFIRST;#WHILE (!%null( %rec)) {
#addkey %concat( "Temp", &Num) %rec
#DBNEXT
}

Now you have bunch of variables named TempXXeq. Each of them contains one data record from your DB.

2nd step - close zMUD and delete *.db file for your database (in my case it was equipment.db)
Now you have left only file equipment.dbd (as in my case) which contains structure of your DB.

3rd step - open zMUD, go to your DB. It should be empty by now. I got error message when zMUD opened DB, ignore it, since I believe that zMUD gaves it because there is no .db file at that moment. If necessary now you can adjust your DB by adding or removing fields.
I suspect that all these problems is caused because zMUD dont know how to work correctly with DB after there are some changes done to its structure.

4th step - copy data back to DB.
Following script does it:
#var itemcount 0
#WHILE (@itemcount <132) {
#echo "Copying Item No:"@itemcount
#var temp @%eval( %concat( "Temp", @itemcount, "eq"))
#new all @temp
#add itemcount 1
}

Only change you have to do is change @itemcount in while statement. I got 132 items (including 0), thus I put the number 132 there.

5th step - clean up. Go to your settings and delete all variables which were created by those scripts.

Hope that will help everyone who got the same problem.

And yep, do not forget to make backup copies of your DB - you never know what can happen next!