Zugg Software :: View topic

Wanderer Joined: 09 Nov 2000 Posts: 66 Location: USA

So I update to MDAC2.7SP1, and I also get jet4 sp7 - I also use the mdac checker to verify that I do indeed have 2.7sp1 - there is just 1 file that doesn't match. Unfortunately room creation still takes forever. So I try to map for a while, but it's just too slow to handle. I dislike having the cpu go to 100% for 5 seconds or more just to create a room. This isn't what bugs me though.. Eventually I figure I'll try a new master map - it'll be a small database, so it should go much faster. I try, and discover that when I try to create a new database it gives me an error of Index not found part way through. This happens whenever I switch to a new database. Even though there is that problem, all it means is that I have to close zmud every time I want to switch. So I get to mapping with a new, small database....thinking that I'll map in this database, then import to my real database. So I map an area, then go to try to import it into my real database.. and discover zmud no longer saves .map files and there is no way to export zones. Apparently you have to use zmapper to do that now, which I don't intend to buy. It all makes me wish I stuck with 6.26a.

Wanderer Joined: 09 Nov 2000 Posts: 66 Location: USA

I forgot one of the other things that really annoys me.

While the mapper is fast and everything during follow mode, If you try to go a direction that doesn't work, it lags. If you are in a room with no exits on the map for example, and then you try to macro somewhere, it is *really* slow. This is due to the new mapper too.. So I've had to make aliases/triggers to turn off/on the mapper constantly, so I don't accidentally macro when I'm not where the mapper thinks I am.

By the way, I don't expect anyone to say anything that might help me with my problems here. As it seems like Zugg is working on something other than zmud now, I will probably try to move back to 6.26a. You could call this just venting steam.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Version 6.26a is a beta version. Beta versions cease to work after a preset expiration time, so you would have to go back 6.16 after the time is up.

I agree that the mapper slowdown is troublesome. As yet no one has been able to pin down what the problem is, but the delays in certain mapper functions seem to be highly exaggerated in XP as compared with all other Windows versions. About a month or so ago was a very long thread that concluded with a number of tests between zMapper and zMud. These tests showed that there are differences in room creation speed. As these 2 programs share a large amount of underlying code, it is likely that the completion of zMapper's beta cycle will find and quash the bugs causing the speed problems with zMud's mapper.

Novice Joined: 16 Mar 2003 Posts: 45 Location: Russia

Megane, I had exactly the same problem, and here is how I solved it: I have MS Access installed. I open database in Access before I launch zMUD, then minimize it, so it stays opened while I'm mudding.

Hope that helps.

Adept Joined: 11 Nov 2000 Posts: 228 Location: USA

Im not a database Guru, But I do know Microsoft likes to put delays in MSDE. They call the technolgy "Target Benchmark Users" I believe the free version of MSDE/Jet will allow upto 5 threads to be open on the db. Once the amount of threads are used, TBU kicks in and slows down all the threads. Something close to that, its been a while sense I read the article. Just something I wanted to toss on the table and see if the issue has been explored before or not.

Wanderer Joined: 09 Nov 2000 Posts: 66 Location: USA

Thanks for warning me about 6.26a. I wouldn't want to do all the work to transfer stuff back to 6.26a after having had to do lots of stuff to transfer to 6.62...only to have to go back to 6.62 again.

As I understood it, zugg had finished working on zmud for the time being..so he's working on zmapper now? I suppose that bodes well for this getting fixed, as I imagine any major speed problems that get fixed with that will end up coming right over to zmud too.

About having microsoft access open while mudding - I tried it, and unfortunately it didn't work for me. Thanks for the suggestion.

I guess I'll throw out another thing thats annoyed me about the new mapper too. It's the follow mode - I hate how it repeatedly locks the map, preventing you from making changes. I made an alias to unlock it, but I have to use it constantly when I'm walking around trying to give rooms ids. I guess It'd be nice if there were the old follow mode, as well as the locked follow mode for those who want it.

Fairly minor, but it's just another thing.

Novice Joined: 16 Mar 2003 Posts: 45 Location: Russia

Megane, have you tried to install MSDE from MS Office distribution?

Wanderer Joined: 09 Nov 2000 Posts: 66 Location: USA

Isn't that an SQL thing?

Posted: Sat Jul 26, 2003 7:03 pm

Has anyone actually tried the SP7 MDAC/Jet files from the Microsoft web site to see if they help with this WinXP problem? I haven't had any trouble at all with the WinXP systems here, but we all know what a mess WinXP really is. It would be nice to find a version of MDAC/Jet that properly installs on WinXP without Windows thinking that it is already installed when it's not.

Be careful with the MDAC files installed by Microsoft Office. Unless you are using the developer edition with MS Access, it doesn't install the latest MDAC files, nor does it do a complete install. Installing Office is actually one of the most common ways to get a messed up MDAC installation on your system (with mixed old/new files). Internet Explorer installation can also sometimes be an issue.

It seems that with much of Microsoft's own software, they don't like to provide the FULL installation of MDAC/Jet, which is why 3rd party developers like myself have so much trouble with them. That is why the exact steps listed on the httpL//www.zuggsoft.com/data page are so important. You need to follow these steps exactly: install latest Windows service pack, install MDAC 2.7SP6, install Jet4SP3, install Jet4SP6.

These Microsoft installers have their own bugs. For example, you can't install Jet4SP6 without installing Jet4SP3 first on some systems because the Jet4SP6 doesn't install the ODBC stuff properly. Some people want to take shortcuts or avoid extra downloads and skip steps, and that can cause problems.

That still doesn't help with the issue on some WinXP systems where Windows already thinks it has the correct version and refused to do the install. I haven't seen a solution to that yet, but would appreciate any suggestions people have.

Unfortunately, there is little I can do about this. This isn't a bug in zMUD that is magically going to get fixed. It's a problem with how various bad versions of the Microsoft MDAC/Jet works. There are several versions that do not use the correct index to perform database lookups which causes the mapper to be very slow. I don't have any way around that. All I can do is tell Windows to use a certain index and do a lookup...I don't have any control over how fast this works or whether it's bugged on some systems.

Wanderer Joined: 09 Nov 2000 Posts: 66 Location: USA

I tried Jet 4.0SP7, I said that in the first post actually. That didn't help me out any. Actually, it sounds like you're getting your OS's mixed up. The data page doesn't say to install jet4SP3 for XP - it does say that for win2000 though. I did exactly as it said - however, I did install office somewhere in there - I think it was before I did anything with the mdac/jet.

Just for the heck of it, I tried installing Jet4SP3(btw, the microsoft link to that is dead) even though I dont think it's meant for XP. Then I installed SP6, and there wasn't any difference.

Wanderer Joined: 09 Nov 2000 Posts: 66 Location: USA

Actually, I think when I tried to install SP6, it wouldn't let me because I had installed SP7 before.

Novice Joined: 16 Mar 2003 Posts: 45 Location: Russia

quote:
Originally posted by Megane

Isn't that an SQL thing?

It is. You can install it from SQL folder of your MS Office distribution. When installed it does a lot of reconfiguration with your database functionality. After I installed it, zMUD stopped to lag when creating new rooms.

Posted: Tue Jul 29, 2003 1:17 am

True, on WinXP you don't *normally* need the JetSP3. The only time you need this is if you are getting ODBC errors. WinXP is supposed to ship with this preinstalled, and I think I removed the SP3 step because it just caused an error message on WinXP (already installed). But this is one of the big problems with WinXP...it *thinks* that some of this stuff is properly installed when it isn't. And Microsoft doesn't give any good way to rollback or uninstall, so once the MDAC/Jet stuff gets installed incorrectly, it's a real pain to fix.

I'm hoping that one of the WinXP experts/gurus eventually find a trick for fixing these problems with WinXP. I use Win2000 for my development system, so I don't have any good way to debug WinXP installations. I have a WinXP test system that works fine, so I've never been able to reproduce the slowdown problems myself.

The MS Office trick is probably worth trying. However, be very careful with *new* versions of Office that are currently in Beta. Anything newer than Office XP will probably install a new/untested/beta version of MDAC, and who knows what trouble that would cause.

Wanderer Joined: 29 Jun 2003 Posts: 64

I am quite adept with WindowsXP, and I already am quite sure of the delay issue. I also have a few suggestions to work around it, such as having the mapper run in a separate thread, so that you can MUD at full speed, and have the mapper "play catchup".
I havent had the opportunity to see the actual coding of the mapper, or how it uses the database, but I am aware that there are similar issues with other programs that use JET databases, while *other* 3rd party programs fly right through it. My guess is there's some optimizations you may be missing out on.
Here is a suggestion though, Zugg, check through and make sure you arent "overworking" the database, by this I mean, make sure you havent put *too much* error-checking, etc. I'm not sure of how you are creating the rooms in the database, but I would see about finding a way to do it with less code.. less code usually = more speed.

Wanderer Joined: 09 Nov 2000 Posts: 66 Location: USA

Interitus, did you install sp3 or sp3a or something else?

Posted: Tue Jul 29, 2003 6:21 pm

zex0s, I don't mean to be rude, but if it was something that easy, I would have already found it. I've worked fulltime for almost a year on this. Why should it work fine on all other versions of Windows, and for *most* WinXP users, but just not for *some* XP users?

The mapper already is in essentially it's own thread, but remember that I'm still having to support Windows95 here, so there are some things I can't do. When following on the MUD, zMUD specifically *must* wait for the mapper to catch up in order for things like room scripts to work. zMUD used to allow MUD input to continue regardless of what the mapper was doing, but that broke people's room scripts that are triggering on output from a room when they move into it.

In terms of the code, we are talking about *very* simple code here. When following the map, depending upon whether the database is set for a client-side or server-side cursor (which is determined by that "Load entire database into memory" preference), zMUD either uses Find or Seek ADO calls to lookup the room based upon the exit from the previous room. Then, if you are still in the same zone, it loops through the exit cache already in memory to form a list of exits from the new room. If you change zones, a new query is sent to the database to load the cache for the new zone first.

When creating a new room, zMUD is issuing a simple INSERT SQL command on both the Room table and the Exit table. I am not using any CONSTRAINTS or FORIEGN KEYS or anything like that. You can look at the tables in Access yourself to see the structure...it's not complicated. I'm not even using anything like AUTOINCREMENT fields, since they are also buggy. But again, zMUD is totally reliant on the speed of the INSERT SQL command, which seems to be slower on some buggy versions of ADO. I have no idea whether the slowdown is in updating the various INDEXes or what...nor do I have anyway to find out...it's all buried in the Microsoft code.

The PROBLEM is with the Seek/Find ADO methods and their use (or not) of the correct index. In some buggy versions of ADO, Windows seems to refuse to use secondary indexes and if your query is not on the primary index, then it takes longer or is not correctly optimized. This might also be related to the INSERT SQL command, or in doing the Seek/Index on the new record once it's added to the database.

ADO/Jet isolates the application from the raw database layer. So, I'm at the mercy of the ADO/Jet drivers to handle things like database lookups. These are not fancy queries or anything like that. They are simple ADO calls to Find/Seek, and simple INSERT SQL commands. Every WHERE clause used in any SQL command has a secondary index defined for it already.

Also, if you have read other threads on this topic, you'll already know that there is at least one zMUD guru who took the time to manually remove all of their existing MDAC/Jet files on WinXP and then installed the correct files from scratch, and this fixed the speed problem. This also indicates that it's a Microsoft MDAC/Jet problem and not a zMUD problem.

What I'm hoping is that someone can come up with a procedure to properly update the WinXP files on these small number of systems experiencing the problem that is simpler to follow than just replacing every file by hand.

Anyway, if you are an ADO expert that can offer more concrete suggestions, then feel free. But don't assume that it's something simple and don't insult me with silly stuff like "less code usually = more speed". We are way beyond simple stuff like that and a lot of work was already applied to optimizing during the Beta testing process, which perhaps you were not a part of. At this point I have yet to see any evidence that the problem isn't just with incorrect MDAC files on some WinXP systems.

Wanderer Joined: 29 Jun 2003 Posts: 64

As I said, it was just a suggestion. And no, my feelings aren't hurt at all. :) And I think you have the problem nailed down, but I was going through my standard "throw even the dumbest suggestions out there" routine. Ya never know when something like that might spark a real idea... I do it all the time at work, and people go "Now that wont work.. but...... " and it sparks another good thought session....

Posted: Wed Jul 30, 2003 3:44 am

Based upon something Carabas found on the Microsoft web site, could anyone that is having the slowdown problem on Windows XP tell me whether they have specifically installed the WinXP Service Pack 1 yet? This is done via the Windows Update command in your Start menu. Apparently the WinXP Service Pack fixes some issues with the MDAC/ADO, and installing MDAC 2.7 SP1 doesn't actually update any files on WinXP even though it claims to have done so successfully.

Wanderer Joined: 29 Jun 2003 Posts: 64

I am already running the service pack.. also verified that my jet files are the current ones.. still rather slow.. took me about 15mins to map 60 rooms...thats 15s a room, and it was a speedwalk path, so wasnt because of my slow typing skills :p

Zex0s

GURU Joined: 28 Sep 2000 Posts: 434 Location: USA

I have Windows XP Pro SP1a with MS Jet 4.0 SP7 at home. I haven't experienced any of the slowdowns, however, my map is very small and any problems may not be noticeable yet.

Would someone be willing to share their map with me so that I could do some testing? [url="mailto:wsfrye@earthlink.net"]email[/url]

Wizard Joined: 14 Oct 2000 Posts: 1368

This can perhaps help: http://support.microsoft.com/default.aspx?scid=kb;en-us;307255
"INFO: Component Checker: Diagnose Problems and Reconfigure MDAC Installations"

GURU Joined: 28 Sep 2000 Posts: 434 Location: USA

Unfortunately, this can only tell you what version of MDAC you have (and whether or not it is a mixed installation) in Windows ME, 2000, and XP. The reconfigure option (/d command line option) is unavailable in those operating systems.

quote:
The reconfiguration option is not available under Windows 2000 or Windows Me because MDAC 2.5 is integrated into these operating systems and should not be removed. Reconfiguration is not available for MDAC 2.7 under Microsoft Windows XP because it is integrated into the Windows XP operating system.

Wizard Joined: 14 Oct 2000 Posts: 1368

quote:
Originally posted by Carabas

Unfortunately, this can only tell you what version of MDAC you have (and whether or not it is a mixed installation) in Windows ME, 2000, and XP. The reconfigure option (/d command line option) is unavailable in those operating systems.

It shows missing files as well. The reason it is "integrated" seems to be that the OS restores the files automaticully if they are changed somehow and that it uses mdac. So in XP it can't be uninstalled Very Happy

.

Wanderer Joined: 29 Jun 2003 Posts: 64

More information on the mapper slowdown..

Not sure if this is related or not, but when I try to move to a room that is not right next to the room I'm currently in, zMUD freezes several seconds while it "figures out" the route to take, obviously, the farther away the room is, the longer zmud takes to figure it out.. not sure if I'm giving any helpful info or not, but i've learned that give it all, and let the developers figure it out.

(too many times, after working on a problem for hours, the complainant comes back and says "oh btw, it also does this" and I'm like "why didnt you tell me before???")

Apprentice Joined: 16 Dec 2002 Posts: 103

I have the slowdown problem, too. It is so bad, in fact, that I've stopped exploring new areas on my mud - totally unacceptable.

My win xp install is fully patched, and none of the suggestions I've seen anywhere help in the least.

I can't help but to wander... hard to imagine that mdac could really be goofy on xp... c'mon - major database api on a major OS. I don't think MS is sloppy enough to let a major flaw ship in something so crucial. At any rate, did you all upgrade from a previous version of zmud, too? Maybe the map converter does something different under xp?

Also, creating a new map makes the slowdown dissapear. Unfortunately, my existing map is _huge_, and the notion of starting over from scratch is not appealing. I also have no way of knowing whether the slowdowns would just manifest themselves again as the map grows large again.

Another important clue, I would think, regarding the nature of the slowdowns... When the slowdowns became manifest, the #find feature began to fail in some cases - #find works in some rooms, but not in others. The follow mode of the mapper tracks my movement flawlessly, though, and I know my configuration is correct.

Additionally, after creating a new map, attempting to load the old one causes a "can't load index" failure, such that the only way to load the original map is to rename the db file. This also, I believe, started at the same time as the mapper slowdown.

One last thing. While the mapper speed is _usually_ ok in follow mode, it does occasionally get choked up. Extremely long speedwalks will almost always cause it to choke up, resulting in disconnects from the mud.

Does this sound familiar to anyone? Please help