Zugg Software :: View topic - [3.09] Didn't convert .MDB, import from 2.37 *Critical*

SubAdmin Joined: 18 Nov 2001 Posts: 5182

A Map setting was created with the orginal .mdb file name. No attempt was made to convert the map database. Subsequently trying to open the mapper leads to an exception stating that the file is not an sqlite file.

After closing, and relaunching CMud; I opened the same session offline. When the first child window was displayed the exception appeared. Selecting Continue from the exception dialog did continue, but the window/layout display sequence had been broken. The first window displayed covered the whole screen; others are listed in the Windows menu, but not displayed.

It would seem that the conversion should occur as soon as the preference value containing the filename is detected. On a successful conversion a Map setting should be added to the package with the correct name. A failure to convert the map file would lead to not writing the preference value in the new package. This would be more easily done by switching the table conversion order.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Looking through the .pkg after conversion I see the that the old .mdb file name is still present in the config table. This entry really should be removed during conversion. The %pref(MapFile) function should look at what Map is relating to the window through its default location object, then return the filename used by that Map object.

I also see that mine had a full explicit path. While the path was still valid it was outside the directory structure to which I had installed 3.09 I would suggest that during the conversion of the package an attempt be made to strip the path, if the mapfile exists and converts using only the filename then it should be stored as just the filename.

Posted: Tue Jul 21, 2009 4:48 pm

Yes, the %pref(MapFile) should be getting reset when converting an old map file. That's left over from some debugging I was doing where I was converting maps over and over again and didn't want this setting changed. I would convert a map, then delete the new DBM file and then run it again to cause it to convert again. If the %pref(MapFile) was updated and then you deleted the new DBM file, it wouldn't be able to find the original MDB file to convert it. But I might be able to kludge it to look for the old MDB file if the DBM file in %pref(MapFile) isn't found.

But back to your original post...

You flagged this as a *critical* issue, but I'm missing the problem that is critical. Maybe I'm still braindead, but I'm having a hard time understanding exactly what you are doing here. Can you give me one of your famous procedures for this one?

I think the Map Object setting in the editor already says something like "Changes to the filename will only take effect when restarting". So CMUD is not going to immediately convert the map when you enter an old MDB filename. It will only convert the map when you close and reload the session. Sounds like that didn't happen for you, but I wasn't able to reproduce it with one of my old MDB files here.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The critical bug was that the .mdb from 2.37 was not converted leaving me with no map to play with. I am working through a possible full procedure now, but it will take a while for CMud's progress bars to twitch through some of the files.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Procedure
1. Copy CMud 2.37 directory to a new directory, call it CMud309
2. Install CMud 3.09 to directory CMud309
3. Launch CMud 3.09 located in directory CMud309 (done from install)
4. Select session that has a map
5. Open selected session offline
6. Confirm that no conversion took place. *Critical bug*
Check directory structures CMud309 and where 2.37 was for .dbm
7. Open Mapper by pressing CTRL-M to see the error that would result in numerous emails of:
Subject: Cmud
Body: Not work.

I suppose I should also test the less paranoid route of copying CMud237's directory, then installing over it as most normal users would. Time for more slow progress bar stuff.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I tried the less paranoid route and installed directly in my 2.37 directory. This caused the SQL error from step 7 of the procedure above to be displayed with the first window of the session. Continuing from the error brought it up a second time. Continuing again let me start playing around with the session.

Checking for the .dbm found no file created, and I never saw any conversion screen go by.

This makes three different import strategies that I have done all resulting in the same error. I could try making a simple recreatable test session if you have any problems reproducing still.

Posted: Wed Jul 22, 2009 2:52 am

Where are your data files located? In my installs, the data files for both 2.37 and 3.09 are in the %documents%. The folder the actual EXE application is installed shouldn't matter.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I use the same directory as program install option. It shouldn't matter though since the 'less paranoid' installation would match a plain install that every regular user is going to be doing. I guess I will take the time to create a procedure that starts at install 2.37.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Procedure
1. Install CMud 2.37
1a. Install directory irrelevant
1b. Set pakcage directory to %DOCUMENTS%...
1c. Run CMud at finish
2. Cancel zMud import
3. Create new session named "t1"
4. Create new session named "t2"
5. Open session "t1" offline
6. Open Mapper (CTRL-M)
7. Select File|Close All from main menu
8. Cancel zMud import
9. Open seesion "t2" offline
10. Open Mapper (CTRL-M)
11. Select "File|Open" from mapper menu
12. Select mdb '%DOCUMENTS%/My Games/CMUD/t1/t1.mdb', and open
13. Close CMud
14. Install CMud 3.09, use all options at installer default, run on finish
15. Open session "t1" offline
Bug 1, no mapper is displayed. There is no value recorded in the package for %pref(MapFile), I am thinking the layout is never looked at, but maybe 2.37 didn't save it right.
16. Open Mapper (CTRL-M)
Bug 2, The t1.mdb is never looked at. A new blank map is created. Verified this with file activity monitor.
17. Select File|Close All from the main menu
18. Open Session "t2" offline
I probably should have checked to see if the Map setting already exists at this point, but it is late.
19. Open Mapper (CTRL-M)
SQL Error! Continue Application
20. Open Package Editor (CTRL-G)
21. Select "t1 Map" setting in PE tree panel
22. Uncheck Autoload on session start
23. Click Save
24. Close CMud
25. Launch CMud
26. Open session "t2" offline
27. Enter at the command line "#10 {#SHOW {Beep}}"
Deleting the Map setting seems to clear up the nasty exception with each line. This makes me wonder what it is trying to do with the database for each line when there is no mapper window, no room properties, and no location objects.

Posted: Thu Jul 23, 2009 7:17 pm

OK, I was able to reproduce this.

Posted: Thu Jul 23, 2009 7:21 pm

Hmm, I actually found the issue with not opening the map window. Turns out to be new in v3.10 with the changes to the mapper docking code. When CMUD sees the UID for the old mapper dock (from 2.37), it was only creating the new window if the Map Object already existed. And when converting from 2.37, the map object doesn't exist yet when the docking layout is loaded. So it was skipping the new window creation. I've got this fixed for v3.10. Thanks for mentioning it in your report.