Zugg Software :: View topic - help convert sql code from Cmud2 to Cmud3

Newbie Joined: 03 Jun 2015 Posts: 5

I have a script made in Cmud2.37, Now in Cmud3.
The map type has been change to .dbm. So I need update the script to work well.

My target is to know the details roomnum list around room 100, the range is 3. below is the code made in Cmud2. anyone can help me?

//
$job_search_list=100
$job_range=3
//

#var rs ""
#VAR rs %comcreate( "ADODB.Recordset")
$connStr=""
$sql=""
$ConnStr=%concat("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=.\Mymud.mdb")
$loopnum=""
#loop 1,$job_range {
$loopnum=1
#loop 1,%numitems($job_search_list) {
$Sql=%concat("SELECT ToID from ExitTbl where FromID = ",%item($job_search_list,$loopnum))
#CALL @rs.Open($Sql,$ConnStr)
#CALL @RS.MoveFirst
#WHILE (not @RS.eof) {
$j=""
$j=@rs.fields(0).value
#if (%roomcost($j)<10000) {#additem $job_search_list $j}
#CALL @RS.MoveNext
}
$loopnum=$loopnum+1
#CALL @RS.close
}
}
$ConnStr=""
#var rs ""
$Sql=""

Sorcerer Joined: 15 Apr 2011 Posts: 809

Running sql queries directly on the mapper database is generally a bad idea. Isn't this just reimplementing the %roomlink function?

Newbie Joined: 03 Jun 2015 Posts: 5

Sorcerer Joined: 15 Apr 2011 Posts: 809

Something like this then?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

CMudv3 gives a series of commands to perform SQL queries. See the SQL Scripting page for information about these features. That will take care of your connection issue.

Your query could be improved to recognize one-way exits that lead to your starting room. Something like this might work for what you want:

Sorcerer Joined: 15 Apr 2011 Posts: 809

As I said though, running sql queries on the mapper database is generally a bad idea. It will not always be reliable as the database is loaded into memory once and changes are not written to the copy on disk until the session is saved. Using the various room and exit functions will always be reliable, and I've found there's very little you can't do with them. If you have CMUDPro, you also have access to the extended zMapper COM interface functions, which gives you even more functionality built-in without ever needing to look at the mapper database.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Daern, your statements were generally true. The increasing number of instances when users sought to query the map database directly was part of the reason Zugg put in more direct SQL access. When you use the SQL commands and functions on the SQL Scripting page CMud should recognize that it is the same data source. Queries for information should always match the most current data. Using SQL updates should be matched by subsequent mapping functions. What is explicitly excluded is map display updates. CMud is not going to take the time to figure out if it needs to update the display from a potentially unrelated SQL statement.

The file commit rate is also selectable by implementors, and Zugg always wanted to ensure that user data was preserved. CMud has a very fast commit rate.

I don't recommend updating the map directly, but queries for information have proven very safe even when the queries went through a separate COM engine.

Newbie Joined: 03 Jun 2015 Posts: 5

Vijilante,thanks. I am a basic user for cmudv3, it seams cannot select the .dbm files within the other files. code like this.
#SQLDB ./mud1/muds.db
anyway, now I output the database to a user datarecord variable, so I no need sql now.

I am confused about the other different between CMUDv3 and CMUDv2.
when I save the door string to path (only door string set as %2)

if there is a door name: push door

in CMUD2 path, e(push door;e)e
in CMUD3 path, e(%2;e)e

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Glad you figured out something for the first issue.

The second issue sounds like a bug. I use the %walk function extensively in my scripts and it does not display that sort of behavior. All I can suggest is that you develop a method using %walk.

Posted: Thu Jul 09, 2015 4:09 pm

For the door problem see my reply in this post.