 |
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
 Posted: Thu Mar 22, 2007 10:46 am
Defining a Database via zScript
|
Is there a way to programmatically define a CMUD database, like equipment?
I'm writing a utility package for my MUD and one module will capture the equipment identify info. However for it to work for the end user I need to be able to make sure their database is set up correctly, and ideally I would be able to do a DB init.
If this is not possible I would like to ask for it as a feature request when the DB gets rewritten. Taking the idea one step further, or as an alternative it would be interesting if we could include DB templates in our uploaded packages, or even pre-populated databases. Sure some people find the thrill of identifying and keeping track of EQ is part of the fun in a MUD but I'm sure there are others who wouldn't mine get largely populate EQ database in one shot. |
|
_________________
Asati di tempari! |
 |
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Thu Mar 22, 2007 11:37 am
|
Asking if there's a way to do something programmatically with zScript is like a red rag to a bull to most people on these forums. If they haven't thought of a way already, they're going to MAKE a way!! :D
That said, it's pretty easy to do. #DBPUT is the main command you'll use but there are a whole host of others for manipulating the data (see this).
A possibly much easier way to distribute a database is just to offer the file for download, though, and then just add updates. |
|
|
|
|
Rainchild
Wizard
Joined: 10 Oct 2000
Posts: 1551
Location: Australia
|
Posted: Thu Mar 22, 2007 10:55 pm
|
Definately can do this via ADO to an Access/SQL database, not sure about a zDB though. I believe when Zugg writes the SQL-based CMUD databases it should be possible to modify tables, assuming the SQLLite allows this.
|
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Fri Mar 23, 2007 1:36 am
|
The CMud database module is not yet rewritten to support any of the actual database formats (ADO, SQL, etc). It, like the mapper, was basically ported over as-is and will be converted, subverted, and diverted into a proper database handler.
Thus, there's no way to programmatically define a database using the CMud database commands and functions. Doing so (assuming you insist on using the DB module as opposed to COM to connect directly to your own) still requires the DB Module UI. |
|
_________________
EDIT: I didn't like my old signature |
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Fri Mar 23, 2007 5:27 am
|
Well I want to do using CMUD's DB component, whatever that is, because this for a package I will distribute. I don't want to make assumption on external databases because not everyone will have it and I want it to be accessible. I guess version 1 of that package will just have to tell the user how to set up the DB and then release version 2 when the DB components get rewritten. Hopefully by then the functionality will be available. I just hope there's no security concerns there... ( for example a malicious package to wipe out the database. ) Maybe some confirmations a la UAC before allowing certain actions.
Fang I know I could use DBPUT to script data but it would kinda tedious to do so (especially since I don't maintain the DB that way). Plus I think it would be better to send the DB with the package... one-stop shopping y'know.
Thanks for the input all. |
|
_________________
Asati di tempari! |
|
|
|
Arminas
Wizard
Joined: 11 Jul 2002
Posts: 1265
Location: USA
|
Posted: Sat Mar 24, 2007 4:15 am
|
Well... I managed to create a database without the UI using only zscript. The whole red flag before a charging bull thing. 
I don't want to post it here though mostly because it would be completely unsupported AND when the database gets rewritten it will probably suddenly cease to work.
I think that if you are going to distribute a package or an importable text file you should at the VERY least send them a database with the records and views defined. Then you can have triggers defined in your package that could fill in the database.
Remember that you can CURRENTLY at least sill use the full path to a file when you open it with #DBLOAD So you could have your users plop the file where they want and use a variable to store the path to the file. |
|
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Sat Mar 24, 2007 7:04 am
|
Hey Arminas, can you PM the code you used to defined the fields. I can dig for the syntax myself now, but I'd rather not right now.
|
|
_________________
Asati di tempari! |
|
|
|
Arminas
Wizard
Joined: 11 Jul 2002
Posts: 1265
Location: USA
|
Posted: Sat Mar 24, 2007 9:36 pm
|
Hrm, I'm going to post a portion of it here. Maybe looking at it and having a short explanation will be enough to put you off the idea!
First I created the database manually with the GUI then I opened it up and looked at it with a Hex editor. THEN I wrote this up to create the files required for the database. This is the part you cannot yet do NORMALLY via Zscript.
Note: I did have this working where I could create the database within the char file in a folder named DB but the darned thing suddenly quit working for that location! So I was forced to use the default location of the Cmud install directory.
Second Note: This is only necisary to define your Fields and create your files. Do not go entering data at this point!
After you know what your two database files look like from the Hex editor you can use the #File and #write commands to create and write your two files. Example Below.
Alias name:
MakeF
Alias value:
| Code: |
#file 1 "test.db"
#call %write(1,%char(4)%char(4)%char(0)test%char(0)%char(0)%char(0)%char(0)%char(0)%char(2)%char(0)%char(0)%char(0)%char(4)%char(0)Name%char(0)%char(1)%char(5)%char(0)Class%char(0)%char(1)%char(0)%char(0)%char(0)%char(0))
#close 1
#file 1 "test.dbd"
#call %write(1,%char(17)%char(4)%char(0)test%char(0)%char(2)%char(0)%char(0)%char(0)%char(4)%char(0)Name%char(0)%char(1)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(193)%char(189)%char(240)%char(255)%char(63)%char(66)%char(15)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(5)%char(0)Class%char(0)%char(1)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(193)%char(189)%char(240)%char(255)%char(63)%char(66)%char(15)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(1)%char(0)%char(0)%char(0)%char(3)%char(0)All%char(0)%char(1)%char(0)%char(0)%char(0)%char(0)%char(2)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(60)%char(0)%char(0)%char(0)%char(0)%char(1)%char(0)%char(0)%char(0)%char(60)%char(0)%char(0)%char(0)%char(0)%char(255)%char(255)%char(255)%char(255)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0)%char(0))
#close 1 |
Once you have your files created you can Load them with #dbload. As mentioned above you can specify a path including a drive letter for #dbload.
After you have this working you can do whatever you want programatically.
Please remember this was just an exercise to see if it COULD be done. And this was also a database with only TWO Fields. I shudder to think of one with more than that. In my opinion it is simply NOT worth it. |
|
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
|
|
|
|
