Zugg Software :: View topic

Enchanter Joined: 10 Oct 2000 Posts: 656 Location: USA

I wish there was a way to abort all changes made during this session.

In zmud I would just not save my settings, but in zmapper if I make some really messed up mistakes, there is no way of exiting without saving the database.

Perhaps if zmapper were to work with a copy of the database and only overwrite the copy if the save button is selected or during exit you are prompted if you want to save your changes. This would be similar to how MS WORD create a temp file copy of your document and if the application bombed both the temp file with the changes and the original are intact.

Talahaski
Processor PIII 1000
Memory 265MB
Video NVIDIA 64MB
Windows XP
Zmud Version 6.34
Zmapper Version 1.10

Posted: Sat Aug 31, 2002 8:08 pm

Sorry, but databases just don't work like that. The only way to "save" a copy that you can restore is with the File/Save As command. Databases are not anything like simply programs like word processors. When you add a record to a database, there is typically changes made to the index (which is a complex hash table), and to reference and contraint fields. All of this is used to provide fast lookup and data consistency so that you don't get "corrupted" files like with the old mapper. So, there is just no way to perform a simple "undo" operation on a database.

The new mapper has a Lock that can be used to prevent changes to the map. This should help prevent unwanted changes that could occur in the old mapper.

Posted: Sun Sep 01, 2002 1:57 pm

You could make a temporary copy of each of the tables involved, and work on those, Zugg. Just because a Database is built like it is, doesn't mean you can't make an undo function. Useful would be a 'snapshot' of each table in memory which is worked on, and saved to the real database on 'save'.
Or, to make an undo function that 'remembers' the reverse of each SQL Statement, which can be applied when the user wants to 'undo' something.

Lady C.

Posted: Sun Sep 01, 2002 6:17 pm

Umm, are you serious??? Really, have you actually ever *tried* to do something like that?? Creating a temporary table and filling it with the existing contents is *slow*. Also, with Jet tables, creating a large Temp table will grow the .MDB file and it's a slow process to recompact that database to get rid of the space no longer used by the temp table.

And this still doesn't cover the issue of indexes and constraints. Internal indexes created to handle "reference" fields would still need to be updated or modified.

Think about it: A room and it's exits involves one record from the "Room" table, and several records from the "Exits" table. These exits could be anywhere in the exit table. There are indexes on the X,Y,Z,ZoneID of the room. Just moving a room on the map changes the X,Y,Z value and requires this index to be updated. Trying to "undo" this change would mean caching the old record and re-updating the index. Undoing a "delete" of this room means caching the room record, along with the corresponding exit records.

Sure, I'm not saying that an "undo" function is impossible. But it would be slow, take up lots of memory, and be a huge programming task. That's an awful lot for what I'd consider a fairly minor feature. Even the old mapper didn't have a good undo function, and people have been happy with that for a long time. Using the SaveAs to create a snapshot of the database seems a lot faster than trying to maintain all the internal consistency needed for an undo function since all it has to do is copy the database file.

By the way, I played with the memory "snapshot" features in ADO a while back. You can tell it to work offline and cache stuff in memory. Then when you are done making changes, you can use the BatchUpdate method to save all the changes to disk. Have you tried this? I have. Changing one record in a small map database and then using BatchUpdate took about 20 seconds!!! BatchUpdate is *incredibly* slow.

Finally, if you've played with Jet databases using ADO, you'll know that the database is *already* cached in memory. It doesn't save stuff to disk every time unless you tell it (which I admit that I often do to avoid possible database corruption). But doing queries and stuff is already using a memory cache. Using a local Jet database is VERY different than using a remote database such as SQL Server or Oracle. Much of the caching that you'd be forced to do for a remote server is already done for you when using a local database.

The speed that you are seeing in zMapper is already the result of a tremendous amount of optimization tricks. The first version of zMapper that I created using ADO required 5 seconds each time you just clicked the scrollbar button! Dragging the scrollbar was out of the question. Creating a new room took about 10 seconds, and dragging a room to a new location also took 10 seconds for each new position of the room (so basically, you couldn't drag it in real time).

zMapper already uses a very complex system of local caches to speed things up. The problem with local caches or extra datasets is that when you make a change to the database, all of these caches need to be updated. The dataset that is used to draw the Exits is a JOIN between the Exit table and the Room table. Unfortunately, updating this data set when a room is moved (which is done when the mouse button is released and the new position is saved) is slow because the SQL JOIN has to be performed again.

Castaway, if you know a lot about using local databases like this, I'd be happy to have an email discussion with you. I'm sure that I'm no expert on all of this and there might be some things I haven't thought of doing. But I think I'm already doing all of the obvious optimizations.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

An undo feauture is really not necessary. What I do is to make a copy of my .mdb file. Windows does this quickly. I then work on my map as mcuh as I want, and any time I'm sure that the map is as I want it, I make the copy again. Any error, and I loose at most what I had done from the last time I made a copy. If you are disciplined enough, this shouldn't be a lot.

Kjata

Posted: Mon Sep 02, 2002 12:06 pm

Hmm, I was serious, actually. I don't do much Jet/ADO though, usually bigger stuff.

On the other hand, I can't really imagine that it's that slow, else nobody would use it.
I'll look into it if I get a chance.. (Not that easy at the mo, as I don't have Access at home in order to look at the mapper database)

BTW: I can't see much speed in the new Mapper yet, I have to wait while it creates each room+exits usually.. But maybe somethings corrupted (That's without importing an old map/mud its all new)

Another suggestion: Just automatically make a copy/backup of the map when the mapper is started, or does it do that already?

(Did you build in those constraints yet? :)

Oh, another thing, is there a document that explains which field is which in the database? Thanks,

Lady C.

Posted: Mon Sep 02, 2002 6:09 pm

I haven't had time to document all of the database tables and fields yet. You'll probably need that to really help a lot (and I would love some help on this from someone who really knows databases).

You can probably figure some of it out by looking at the Export option in zMapper. It at least shows the table names and by exporting each table to a text file you could see the field names.

I never added the Delete contraint that we talked about. It turned out that deleting rooms was more complicated than that. You don't actually want to delete the Exits pointing to the room...you want to turn them into Null links (those stubby links). I'm still considering the creation of a temp table of the selected room IDs to handle that case to see if it's any faster.

I'm actually considering *eliminating* many of the database contraints. For example, I use several "Reference" fields, like:

FromID INTEGER REFERENCES ObjectTbl (ObjID)

is the field in the ExitTbl that points to the room record on the "from" side of the exit. Supposedly these "reference" fields create their own internal indicies. And it's these Reference constraints that determine if there are still some records using a record in some other table.

My guess is that the overhead for these kind of fields is rather high. I'm considering making them normal fields and adding an separate index manually. Maybe you've had some experience with this?

In general, however, I find Access much different from SQL Server. Optimizations I've seen in many database programming books actually make things slower with a local Access database. And I haven't been able to find any really good books on Jet programming. All of the MS Access books talk about the Access application rather than the underlying database technology.

Enchanter Joined: 10 Oct 2000 Posts: 656 Location: USA

Actually, I was not thinking about an undo option. That would be nice but its not requires. I was suggesting basically to do what Kjata does now manually.

Upon open of a map file, perform a copy file statement. Copy TESTMAP.mdb to TESTMAP.tmp. Open and work with TESTMAP.tmp. Upon save or exit requesting save, update TESTMAP.tmp as needed, delete TESTMAP.mdb, rename TESMAP.tmp to TESTMAP.mdb. If exit requesting not to save--along with warning messages of losing data, just delete the TESTMAP.tmp and exit.

I'm not sure if your concerned about the time it would take to issue a system copy command. I would not guess that it would take too long. But if that is a concern, perhap have a option for users to decide if they want to work on a copy or the original.

Anyway, this is just a thought.

Talahaski
Processor PIII 1000
Memory 265MB
Video NVIDIA 64MB
Windows XP
Zmud Version 6.34
Zmapper Version 1.10

Posted: Tue Sep 03, 2002 8:07 pm

Perhaps in the File menu, along with the SaveAs function (which does a copy and will then switch to using the new copy), I'll add a Backup function which would do the copy to a filename_bak.mdb name automatically without changing the current database.

GURU Joined: 10 Oct 2000 Posts: 1116 Location: USA

In SQL Server and Oracle, you can use commit and rollback, but seeing as how you're not using either, than it's a moot point, heh. Would the backup be able to be automated somehow? Like, once you hit the edit map button, it automatically backs up, then when you change back to follow mode, or when you exit zMUD, it'll ask if you want to save changes. How's that sound?

Iljhar

Posted: Wed Sep 04, 2002 8:42 am

Sounds good to me..

Zugg, you're probably right about references and such slowing everything down.. It's better not to connect them directly at all, unless you actually use the functions like cascading delete etc. I know our DB2 application doesn't use anything like that at all, and its supposed to be optimized for speed.. :)

(BTW, when I delete a room, 99% of the time its because the mapper drew an exit+room where I didn't intend it to be, and I need to get rid of the exit as well ;)

Hmm, I wanted to make a trip to my local computer-book shop anyway, maybe I'll find one..

Lady C.