|
devyn Beginner
Joined: 26 Jul 2002 Posts: 13
|
Posted: Fri May 07, 2004 9:39 pm
dbput and strange variable usage |
Hi, I'm currently writing a script for a bot, and I am saving records to a database for each person that uses the bot. When I do a query, I get the information and store it in a variable of their name (i.e. if Devyn used the bot, there would be a variable @Devyn). This makes for some interesting parsing with db records...I am using @<@name>.field to get the values of the fields in the variable. When I try to store the entire in the same manner as in the #dbput help example:
#dbput @<@name>.Num @name
the record is not updated. However, when I update the fields individually:
#dbput @<@name>.Num {field1=val1|field2=val2}
the values are updated correctly. Is there something wrong with using #dbput with an entire record?
-Devyn Draen |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Fri May 07, 2004 10:50 pm |
There might be someting wrong with it. I noticed a similar problem sometime ago with #ADDKEY %rec. You might try using the correct syntax for your indirect reference:
#dbput @{@{name}.Num} {field1=val1|field2=val2} |
|
|
|
devyn Beginner
Joined: 26 Jul 2002 Posts: 13
|
Posted: Sat May 08, 2004 10:21 pm |
Thanks for the help with the variables. Now I'm running into a rather strange problem with #dbput. Apparently with #dbput, if I try to put into a record that is not the currently selected record in the GUI, even if I specify the correct record number, it ends up making a duplicate of the selected record. For example,
Devyn is the currently selected record in the GUI with number 199mi
Kolchin is unselected, but I want to put the value into that record - the number for Kolchin is 198mi
When I execute:
#dbput 198mi field value
Kolchin(198mi) is replaced with a copy of Devyn(199mi) with the correct field value (the old Devyn(199mi) is not changed). Both the copy and the original Devyn(199mi) have the same record number.
I really have no idea why this would be causing a problem, I assume it is because #dbput updates %rec regardless of what you tell it to do. I devised a way around it: simply do "#dbget @numrecord" to set the current record to @numrecord.
However, I'm not sure how zmud's triggers work with this. If something is triggered while another trigger is running, would both triggers process concurrently (e.g. Java's Threads)? If so, then this #dbget would be a nasty critical section in my program since I allow the database to be accessed by multiple users at the same time.
Are there any alternative methods to update the value of a record key in the database itself? Unless I'm mistaken, all the other functions listed in help simply affect a database variable. I'm also trying to avoid using %rec because of the possibility of critical sections.
Of course, I'm a newbie at databases (in general), so maybe I'm just all turned around backwards on the whole thing So, any advice would be greatly appreciated, thanks.
-Devyn Draen |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Sun May 09, 2004 3:09 pm |
Triggers are processed semi-concurrently. The way it works is all triggers are tested for a given line. Those that are fired by are flagged for processing. The scripts are processed sequentially at this point. If a looping command is encountered in the current script then that script is held and the next is started. Once all scripts have been given a chance to go then the mud is checked for further input. Finally all the held scripts are resumed again sequentially. Further loops in a script would cause it to be held again and the rest of the sequence above would happen again. This holding behavior is designed to speed up overall processing of the scripts by doing slower activities during a time when the mud is waiting. You can override this behavior by using the #PRIORITY command.
|
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|