The Database module in zMUD looks a lot more powerful than data record variables, with one big problem. If the Database window is closed, all the relevant scripting functions stop working, regardless of whether I #dbload or even go #dboffline. Even %rec.Field returns a null string. Anyone ever worked with it as a data repository for scripts, and if so, found a workaround or solution for this problem?

I've not worked with the database module much in zMUD, but I do know that you have to have the database window open for the queries to work properly. You can get it out of the way, so it doesn't bug you too much, but it has to be there.

It's also not a true database, just like data record variables aren't really hashtables like they ought to be, so it's slower than a real database.

Having the window open isn't a problem for me. The trouble is having to require anyone who buys my script to have it open, and ensuring that it is open. I suppose I can kluge around it by using the #menu command to force it open if it isn't, though. Just seems so clunky.

Is it possible to use a real database from the script system without requiring the user to do anything other than run my scripts?

As you said, you could use your script to force the window open, but for scripts you distribute to others, I really wouldn't recommend it. The database system is more trouble than it's worth, in my opinion, so you're better off keeping things well-encapsulated just using variables. I'm hoping that when Zugg re-writes the database system in CMUD that he doesn't keep the "window opened" requirement...

Problem I'm having with them is an invisible size limit. You can add data to a data record variable all day and it keeps working. Close zMUD and reopen it, and the data vanishes, all of it, if it got too big in the previous session. Working around that is going to be a hideous ugly kluge. I guess as with many things zMUD, it's a question of which kluge is uglier.

The other upside of the database module is that it's so much faster than data records, even if it's still not as fast as one would like it to be.

How much stuff are you putting into a data record variable? I've had some enormous data record variables and no trouble with the data being lost. Are you sure you're not setting a default value or doing something else that could cause the effect you're seeing?

Almost 200 records each containing a paragraph (an examined description) in the one case where it's failing. That's how many ring designs Ialie has available to her. It works fine while connected but loses the contents over a reconnect. It's definitely not a default value thing; I've reproduced it myself here (as could you, just create a data record var, use a loop to #addkey a long item description to it 200 times, verify its contents, then shut down and reopen zMUD).

I can force the database window open if it's not; can I force it minimized from a script? If so, that might be the least bad way to go.

I use a 150-entry data record or so in Cmud, and it's not fully built yet.. need to finish adding the afflictions.

Strangely, though, it's the most reliable data record I have - my 5-entry list data record often erases itself.

You're absolutely right. I created 250 records, borrowing a paragraph from your post as the test value, and after closing and re-opening zMUD, I now have only 113 and the last is incomplete. It's not too surprising that this happens, really, given that Zugg is only using a string variable internally to store the entire contents of the data records.

The re-built strings and data records in CMUD will definitely correct a lot of problems like this. I'm really looking forward to the new 2.0, even if it does start another beta cycle.