Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ VBscript ➜ Handling numerous speedwalks - and using a database

Handling numerous speedwalks - and using a database

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1 2  3  4  

Posted by Jeffrey F. Pia   (49 posts)  Bio
Date Fri 26 Jul 2002 10:59 PM (UTC)
Message
What is the best way to handle speedwalks? I have about 175 SWs to different area... not too bad, right? I could prolly just make aliases for em all... here's the kicker: I am collecting SWs to the various stationary mobs in each area too. Say there's an avg of 10 per area... probably more, but just for an example. What's the best way to store these SWs? I would probably want to call the SW by typing SW <area nickname> to get to the begining of the area, or SW <area nickname> <mob nickname>. Seems like I'd have to write a script containing an array... would I have to make an array for each area as well? Or would some type of 3 dimensional array would work? Thanks for any new ideas!
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #1 on Sat 27 Jul 2002 12:47 AM (UTC)
Message
One fairly simple approach would be to store each one as a variable, replacing the space between the area and mob name with an underscore, and prefixing it with something. eg.

area = darkhaven, mob = storekeeper

variable = sw_darkhaven_storekeeper

MUSHclient internally looks up variables by name quite efficiently, so it should be fast to look for a particular one.

Then make an alias "SW *" (or maybe two, "SW *" and "SW * *" to detect the second case).

The alias could concatenate the wildcards appropriately and look up the speedwalk variable, eg.

sw = world.getvariable ("sw_" & wildcards (1) & "_" & wildcards (2))

Then evaluate and send it, eg.

world.send world.evaluatespeedwalk (sw)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Jeffrey F. Pia   (49 posts)  Bio
Date Reply #2 on Mon 19 Aug 2002 09:07 PM (UTC)
Message
I like the idea... it's simple and easy, but I can see it's application being rather rigid and non flexible. I can also see making a listing of available areas as a chaotic mess of text parsing, or a second list which would need updating. What I have now is a table in Excel listing the Area Name, Mob Name, Room Name, and SW. What I *can* do is save this list in delimited text format. What I would *like* to do is keep that list separate from my main code, and only load it when I use my alias for SWs. I like the convenience of updating the information on a spreadsheet, and saving the list as a text file is quick and painless. Is there a way to load the file, similar to loading a separate script file, and have it populate an array? I can then loop through the array to find a match. I am not sure how processor intensive working with arrays is however. I was also thinking about creating a separate file for each area, to aid in updating and avoiding duplicating entries (a small list is easier to double check than a large list). Each area can have between 25 and 400 room, and about the same number of mobs, all of which require their own SW. As it won't change very often, I was thinking about keeping just the main SW to each area in my script file for quick access, and every other (secondary if you will) SW in these separate files. I think I can handle all the coding if I can just get the info from a seperate file into an array. What do you think? Is this doable? Is ODBC a more viable alternative?
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #3 on Mon 19 Aug 2002 10:02 PM (UTC)
Message
I am rapidly coming to the conclusion that ODBC is the 'only' way to do things. Even my simple Druid Potion plugin has caused me more headaches due to fiddling with arrays, strings, splitting strings into arrays, joining them back to strings, etc, etc... that I have ever had writting anything. The lack of true type casting is part of the problem, but having to shift everything around between mushclient variables and script arrays is a major pain. A set of files is not much better, since you end up lagging the client slightly each time it has to read in the file. Also.. I am not sure how or if you could store it in a file and make it work reasonable well. :p

The only reason I haven't change the potion plugin over is I also haven't sat down with an ODBC manual to try and figure out how to create the database from in the script. I don't really want to include it as another file with the plugin, since I don't want it to contain anything initially. Of course with ODBC you should also be able to access you existing Excel spreadsheet. I know it is supposed to be possible. Just don't ask me how. ;)
Top

Posted by Jeffrey F. Pia   (49 posts)  Bio
Date Reply #4 on Wed 28 Aug 2002 04:41 PM (UTC)
Message
Anyone have an example of what the VBscript code for an ODBC query looks like and/or a website that touches on the topic?
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #5 on Wed 28 Aug 2002 08:25 PM (UTC)
Message
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndao/html/daotoadoupdate.asp

If it doesn't load, just search for 'migrating DAO to ADO'. ;)

This requires some hunting to find stuff and some guess work. For instance, from a previous post I can guess that creating a database works a bit like this:

dim cat
cat = CreateObject("ADOX.Catalog")
cat.Create "Provider=Microsoft.Jet.OLEDB.4.0;Datasource=.\MyNewDB.MDB;"

However without testing is this is a major guess. I am not even sure ADOX is correct, since the normal set of ADO commands are prefixed ADODB. :p However, it is likely right, since ADOX is apparently an extension of the commands you normally can use. But basically since this is neither true VB nor 'normal' VBscript, any place where you would normallly do:

dim Something as new COMThingy.Element

or the complicated CLSID=Blahblahblah stuff, you have to use:

dim Something
Something = CreateObject("COMThingy.Element")

instead. But as I said. This is a guess based on other observations and is made even more comfusing by the fact that Javascript actually supports the 'normal' method that you would use in pure VB. :p We really need an example tutorial on this stuff for the supported script types. lol
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #6 on Wed 28 Aug 2002 09:37 PM (UTC)
Message
>dim cat
>cat = CreateObject("ADOX.Catalog")
>cat.Create "Provider=Microsoft.Jet.OLEDB.4.0;Datasource=.\MyNewDB.MDB;"

Hmm.. This is really odd..

Checking the typename I get 'Table', so I assume it is creating the object, but the ADOX object insists that is doesn't support the Create property or method. :p Either MS's page lies or I did something wrong, just wish I had a clue what... $#$%^#...
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #7 on Thu 29 Aug 2002 04:57 AM (UTC)
Message
Try this post: Can I access SQL database in MUSHclient with Jscript? . This is for Jscript but the technique is pretty identical in VB.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #8 on Thu 29 Aug 2002 07:34 AM (UTC)
Message
True. That is where you should likely start looking, though... There is another post that is more accurate. As I said, you have to remember to use CreateObject, where full VB and java both use New. That can be seriously confusing till you realize the difference.

------
This doesn't help me much though. ADOX is supposed to support 'creation' of a database. I would like to avoid A) including an existing database with a plugin or B) forcing someone to use the ODBC control panel to make one. :p

Mushclient can be a very strange animal with this sort of thing and you can't use the usual COM controls for databases to create one, but you also don't have access to DBEngine, which is the way you would normally create one in full VB. This is very frustrating and limits ones options.

This and the fact that I can find no simple way in VB to support the creation of non-predeclared Activex controls in VB is bugging the heck out of me. I know both should be possible, but there just isn't any decent documentation on either one, not even at the MS website. I hate the idea
of having to pre-make a database. I also, in the case of the ActiveX controls problem, don't really feel like fighting with C++ and MFC to get around VB's limits in this respect, but I may have to.

Apparently it never occured to MS that someone would ever want databases that are accessed by scripts, but not pre-existing and programs that impliment VBscript, but lack the ability to display ActiveX controls. lol It is making life quite interesting for me.
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #9 on Thu 29 Aug 2002 08:14 AM (UTC)
Message
Quote:

This doesn't help me much though. ADOX is supposed to support 'creation' of a database. I would like to avoid A) including an existing database with a plugin or B) forcing someone to use the ODBC control panel to make one.


That should be theoretically possible. :)

The ODBC control panel doesn't strictly speaking make databases, it links to an existing one. If we could make one via 'create table' in the plugin (if necessary) then it should be possible to access it. Maybe.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #10 on Thu 29 Aug 2002 06:24 PM (UTC)

Amended on Thu 29 Aug 2002 06:25 PM (UTC) by Shadowfyr

Message
Well... Actually the control panel 'can' create one. Also, create table doesn't generate a database itself, it mearly adds a new 'table' to an existing database source. It you have no Data source to connect to, you can't connect to it and create a table.

Basically it seems to work like this:

ADOX, DBEngine or ODBC Control Panel
|
\____Create
        |
        V
      Driver _____  (Mydata.MDB is created here.)
                 _\|
      Driver <--> Data Source (Mydata.MDB)
        ^
        |
        V
 ____Connect to Data Source
/
ADODB and ODBC


And database actually looks like:

Data source (Mydata.MDB)
|
|-Table (MyTable) - This is what ADODB creates and contains the 'database'.
|     \
|      Records
|
|-Table (FredsTable)
|
Etc.


Both connect you 'through' the database driver, but ADODDB and ODBC where, I think, intentionally designed to limit the ability to actually create a data source file to system admins and programs which hard code file creation into themselves (like Excel). There are no ActiveX controls that provide this except ADOX and it keeps telling me that the method isn't supported. :p

Now... I could provide a single pre-created datasource, but then I would have to either copy and rename it some how for each world or create a seperate table for each world within it. The problem with the first option is I am not sure you can do so in scripting, while the second means if someone moves the data file, thinking it is only connected to one world, all the others stop working as well. :p It looks like it may turn out to be the only way to make it work though, since I can't find another solution.

Basically, with ADOX not working, the ODBC control panel being to confusing to use imho and no access to DBEngine (which I am fairly sure is not a COM object), there just isn't a way to create a new file from inside a script.
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #11 on Thu 29 Aug 2002 08:59 PM (UTC)
Message
Quote:

create table doesn't generate a database itself, it mearly adds a new 'table' to an existing database source


True, you need 'create database' for that.

I'll have to experiment a bit. Your examples imply the use of Access which I wouldn't use these days, for one thing it doesn't really support - readily - access from multiple PCs. Secondly, not everyone has Office with Access (Access is an optional extra, and isn't cheap).

I would use mySQL, which is Open Source, and rather than create one database per world, create either a table per world, or probably better, a single table with a "world id" column in it. Otherwise you end up cluttering your disk with lots of database files.

As for ODBC, I'll take a look at adding support for mySQL natively into MUSHclient, which gets around the need for any ODBC interaction at all. However there may be a problem linking it unless mySQL is compiled into it, which may bloat it. I'll check it out, it might not be too bad.

That would be very helpful for people who want to keep lots of data, as it would be fast, and also save immediately, even if the world itself crashes for some reason. Then you could write stand-alone tools (eg. using Access) that access the data and play with it.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #12 on Thu 29 Aug 2002 11:18 PM (UTC)
Message
Actually.. A standard install of windows has the ODBC drivers for Foxpro, Excel, Access, and several others available through the Jet libraries. Unless you are running maybe a real old version of 95, those drivers should be there and accessable through ADO. The problem is just that there is not a way to create one, only access those that exist. You don't have to have Access installed to use them.

On the other hand MySQL has to be installed seperately and that goes right back to the original problem of needing some extra program or file that you shouldn't need to install to use the existing functions. :p I am not sure that is really a good solution to the problem, though if you ever ported mushclient to Linux, then maybe it would make sense. For now though...
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #13 on Fri 30 Aug 2002 02:21 AM (UTC)
Message
Quote:

>dim cat
>cat = CreateObject("ADOX.Catalog")
>cat.Create "Provider=Microsoft.Jet.OLEDB.4.0;Datasource=.\MyNewDB.MDB;"
Hmm.. This is really odd..
Checking the typename I get 'Table', so I assume it is creating the object, but the ADOX object insists that is doesn't support the Create property or method.


I got that to work with minor variations. It is important to use the word "set" - I think that is where your example went wrong.

The code below gives two scripts, one creates a database (I presume you would have some sort of check to see if it already exists).

The second creates a table. I pulled out the constant definitions from the help file to make creating the table easier.

I haven't done the recordset selection etc., which is the trivial stuff once you have this going.




const adBigInt = 20 
const adBinary = 128 
const adBoolean = 11 
const adBSTR = 8 
const adChapter = 136 
const adChar = 129 
const adCurrency = 6 
const adDate = 7 
const adDBDate = 133 
const adDBTime = 134 
const adDBTimeStamp = 135 
const adDecimal = 14 
const adDouble = 5 
const adEmpty = 0 
const adError = 10 
const adFileTime = 64 
const adGUID = 72 
const adIDispatch = 9 
const adInteger = 3 
const adIUnknown = 13 
const adLongVarBinary = 205 
const adLongVarChar = 201 
const adLongVarWChar = 203 
const adNumeric = 131 
const adPropVariant = 138 
const adSingle = 4 
const adSmallInt = 2 
const adTinyInt = 16 
const adUnsignedBigInt = 21 
const adUnsignedInt = 19 
const adUnsignedSmallInt = 18 
const adUnsignedTinyInt = 17 
const adUserDefined = 132 
const adVarBinary = 204 
const adVarChar = 200 
const adVariant = 12 
const adVarNumeric = 139 
const adVarWChar = 202 
const adWChar = 130 

sub CreateDatabase
Dim catDB 
Set catDB = CreateObject ("ADOX.Catalog")
catDB.Create "Provider=Microsoft.Jet.OLEDB.4.0;" & _
              "Data Source=c:\mushclient\mydb.mdb;" & _
              "Jet OLEDB:Engine Type=5;"

Set catDB = Nothing
end sub

sub CreateTable
dim catDB
dim tblNew
Set catDB = CreateObject ("ADOX.Catalog")

 ' Open the catalog.
 catDB.ActiveConnection = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
    "Data Source=c:\mushclient\mydb.mdb"

 Set tblNew = CreateObject ("ADOX.Table")
  With tblNew
   ' Create a new Table object.
   .Name = "Contacts"
    ' Create fields and append them to the 
    ' Columns collection of the new Table object.
     With .Columns
       .Append "FirstName", adVarWChar 
       .Append "LastName", adVarWChar 
       .Append "Phone", adVarWChar 
       .Append "Notes", adLongVarWChar 
     End With
  End With
  ' Add the new Table to the Tables collection of the database.
 catDB.Tables.Append tblNew
   
Set tblNew = nothing
Set catDB = Nothing
end sub

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #14 on Fri 30 Aug 2002 02:24 AM (UTC)
Message
Note how the example doesn't use the ODBC control panel at all, so you should be able to slot it into a plugin.

In the line:

Jet OLEDB:Engine Type=5

If you use "type=4" you get an Access 97 database, whilst Type=5 gives an Access 2000 database. You might want to use Type=4, however I found that on my PC to open it in Access I had to convert it (to 2000) anyway, so it was no big saving.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


145,837 views.

This is page 1, subject is 4 pages long: 1 2  3  4  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.