Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Sun Apr 05, 2009 7:05 pm   

[3.05] Mapper Primary Key Crash
 
I just sent in an error report on a crash I'm having. right now, i can't create a new room manually in my map, each time I try I get an error saying "primary key must be unique". I don't know why, but I'm suspecting the room number it is trying to create has already been used. Since I don't know what number it's trying to use, I can't check to see if it has been used.
here is the general and call stacks
Code:

date/time         : 2009-04-05, 13:58:16, 933ms
computer name     : CHACHIESBOX
user name         : Administrator <admin>
registered owner  : chachie
operating system  : Windows Vista Service Pack 1 build 6001
system language   : English
system up time    : 3 hours 57 minutes
program up time   : 14 minutes 58 seconds
processors        : 2x Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
physical memory   : 541/2046 MB (free/total)
free disk space   : (C:) 58.95 GB
display mode      : 1600x1200, 32 bit
process id        : $1b68
allocated memory  : 108.35 MB
executable        : cMUD.exe
exec. date/time   : 2009-03-11 18:05
version           : 3.5.0.0
compiled with     : BCB 2006/07
madExcept version : 3.0h
callstack crc     : $06a99d80, $761b1ea4, $761b1ea4
exception number  : 2
exception class   : EZDatabaseError
exception message : SQL Error: PRIMARY KEY must be unique.

Main ($198c):
00893699 +000e9 cMUD.exe     ZAbstractDataset     417  +14 TZAbstractDataset.InternalAddRecord
77d79b66 +00081 ntdll.dll                                  RtlRaiseStatus
76ad42e5 +00052 kernel32.dll                               RaiseException
77d79b66 +00081 ntdll.dll                                  RtlRaiseStatus
77d799f2 +0000a ntdll.dll                                  KiUserExceptionDispatcher
00867802 +0002a cMUD.exe     ZDbcStatement       2000   +1 TZEmulatedPreparedStatement.ExecuteUpdate
00867902 +0002a cMUD.exe     ZDbcStatement       2040   +1 TZEmulatedPreparedStatement.ExecuteUpdatePrepared
0085d044 +0014c cMUD.exe     ZDbcGenericResolver  776  +26 TZGenericCachedResolver.PostUpdates
00884910 +00038 cMUD.exe     ZDbcSqLiteResultSet  853   +1 TZSQLiteCachedResolver.PostUpdates
0085e77c +00018 cMUD.exe     ZDbcCachedResultSet  439   +5 TZAbstractCachedResultSet.PostRowUpdates
0085e8f4 +0005c cMUD.exe     ZDbcCachedResultSet  545  +14 TZAbstractCachedResultSet.PostUpdates
0085f26c +00080 cMUD.exe     ZDbcCachedResultSet 1526  +16 TZAbstractCachedResultSet.InsertRow
00893668 +000b8 cMUD.exe     ZAbstractDataset     415  +12 TZAbstractDataset.InternalAddRecord
00893840 +0010c cMUD.exe     ZAbstractDataset     465  +19 TZAbstractDataset.InternalPost
0051737d +00029 cMUD.exe     DB                            TDataSet.CheckOperation
00517018 +00048 cMUD.exe     DB                            TDataSet.Post
00d39519 +00241 cMUD.exe     MapList3            3300  +29 TMapNode.MakeRoom
00a53758 +0007c cMUD.exe     MapFrame3           6535   +4 TMapFr.MakeRoom
00a41a66 +00afe cMUD.exe     MapFrame3           1863 +145 TMapFr.MouseBoxMouseDown
00cf7596 +0004e cMUD.exe     MapNew3             1359   +6 TNewMapF.MapMouseBoxMouseDown
004bb57b +0002b cMUD.exe     Controls                      TControl.MouseDown
004bb5fe +00076 cMUD.exe     Controls                      TControl.DoMouseDown
004bb64c +00040 cMUD.exe     Controls                      TControl.WMLButtonDown
004bb023 +002bb cMUD.exe     Controls                      TControl.WndProc
77d799cb +0002b ntdll.dll                                  KiUserCallbackDispatcher
77860b69 +37f36 USER32.dll                                 CallNextHookEx
004bacb0 +00024 cMUD.exe     Controls                      TControl.Perform
004be846 +000aa cMUD.exe     Controls                      GetControlAtPos
004be90e +000a6 cMUD.exe     Controls                      TWinControl.ControlAtPos
004bacb0 +00024 cMUD.exe     Controls                      TControl.Perform
004beb19 +000a1 cMUD.exe     Controls                      TWinControl.IsControlMouseMsg
004beee1 +003b5 cMUD.exe     Controls                      TWinControl.WndProc
004be750 +0002c cMUD.exe     Controls                      TWinControl.MainWndProc
0047c400 +00014 cMUD.exe     Classes                       StdWndProc
77835a27 +0000a USER32.dll                                 DispatchMessageA
004a96fc +000fc cMUD.exe     Forms                         TApplication.ProcessMessage
004a9736 +0000a cMUD.exe     Forms                         TApplication.HandleMessage
004a9a2b +000b3 cMUD.exe     Forms                         TApplication.Run
00df7214 +00088 cMUD.exe     CMUD                 352  +20 initialization
76ad490f +00010 kernel32.dll                               BaseThreadInitThunk



Edit by Fang: Removed some personal info from the crash dump.
Reply with quote
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Sun Apr 05, 2009 10:22 pm   
 
In looking at my map in the spreadsheet view, after filtering for all, I've found a bunch of rooms tith a refnum set to zero.... I think this could be the reason for the crash, but my question would be how did they get set to zero?
Reply with quote
orphean
Apprentice


Joined: 21 Oct 2008
Posts: 147
Location: Olympia, WA

PostPosted: Mon Apr 06, 2009 10:56 am   
 
I got the same error earlier today trying to get the automapper setup on Aardwolf. So you're not alone (small consolation that)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Apr 06, 2009 6:59 pm   
 
Please email me your *.DBM map database file to sales@zuggsoft.com so that I can take a look at it and determine how this happened.
Reply with quote
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Wed Apr 08, 2009 1:56 am   
 
Emailed two packages with two .dbm maps. I've also had this happen again since my first post. I've tried a few things to try to get it to fail, but havn't gotten it to on purpose yet. One thing I've noticed is when I do a #fin command from the command line to find where I am in the mud, the mapper changes from follow mode to map mode then back very quickly. Seems that the mapper shouldn't have to go into map mode to find where I am...?
Reply with quote
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Wed Apr 08, 2009 2:17 am   
 
Ok so heres a theory. I've got my script debugger running, and when I do a #fin command to find myself in the mud, I noticed two lines in the debugger (classified as k which is a variable change) that indicated
Code:
loc "jed" changed from "2" to "0"
loc"jed" changed from "0" to "39"

Seems to me that it should change my location directly from 2 to 39, rather than changing it to 0 first. Also, is there any chance that changing my location from 2 to 0 (remembering that the mapper is in map mode because when you do a #fin it intermittently changes the mapper to map mode) inadvertently changes the roomvnum to 0?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Apr 09, 2009 4:28 pm   
 
I got your files, but haven't learned much from them. Certainly once you get rooms with a vnum set to zero, it will cause the original error. The question is how those rooms got a vnum changed to zero in the first place. Changing the location object doesn't have any effect on the room's vnum. The vnum is the primary key of the map database and is incrementally by the database automatically when rooms are added.

Was your original map file converted from zMUD? Maybe the original zMUD file has a problem in it?

The reason why the #FIND command goes into map mode momentarily is because it needs to parse the output of the MUD to detect the room name, description, and exits, just as if it was going to create a new room. CMUD only parses the full MUD output like this in Map mode.

The changing of the location object in the debug output is interesting and something I'll look at, but I don't see how this could cause any effect on the vnum in the database.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Thu Apr 09, 2009 5:16 pm   
 
I have been finding that if i color a room, then go to map a new room (in an active session), it will often error with that same message.
After several of these I have noticed a pile of rooms in the first zone i created.
So each time it errors for me it is actually creating a room, just not anywhere close to the currently/selected room.
_________________
Discord: Shalimarwildcat
Reply with quote
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Thu Apr 09, 2009 9:57 pm   
 
Yes, it was imported from zmud. I'll try to check some older files to see if the zeros existed there, and to see if there are multiple rooms with the same
refnum as I am now finding.
As I say, I now have multiple rooms with the same refnum. I originally had a room with a refnum of 4. Along the way, somehow it got changed to 0. Not knowing exatly how to change it back, I decided to delete it and then recreate it. When I deleted it, the links to it from other rooms, appeared with the little black box on the end of it, indicating the link was now connected to a room in another zone. At that time, I checked the spreadsheet, and now see that I have multiple rooms with the same refnum (4 is one that has multiple rooms so maybe this will help zugg..). What is the difference between refnum and objid in the spreadsheet view?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Apr 09, 2009 10:09 pm   
 
The ObjID is the actual primary key of the database and must be unique. The RefNum is a user-defined room number that defaults to the same value as ObjID, but doesn't actually need to be unique (as far as database errors are concerned). That's why I'm having such a hard time reproducing this...the RefNum field shouldn't be related to your original crash post. The original crash post was caused by having the same ObjId in the database (or trying to add a new record with the same ObjId as a previous record). The ObjId field is auto-incremented by the database and should never have a duplicate collision like that. So my guess is that there was something corrupted in the original zMUD file that is causing this somehow.
Reply with quote
diabolos
Newbie


Joined: 12 May 2011
Posts: 3

PostPosted: Thu May 12, 2011 11:01 pm   
 
I hate to necro this problem but probably better then starting a brand new thread with similar information.

I have had this problem since I installed CMUD 3.34. and I did NOT get this after importing the maps and converting.. in fact, I didnt have a Materia Magica session until I got CMUD 3.34.

I get this error about every 5-10 new rooms and it is really geting on my nerves.

*UPDATE* This seems to happen to me when I select mass rooms (usually 5 or more) and select a color for the rooms.
I even erased the DB after I made a backup of it and started a brand new DB, I made about 50 rooms and updated the color, and as soon as I went to create another new room.. it crashed.
This is very annoying!

please help!

(Feel free to move this to another thread if you must)
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net