DragonPrime - LoGD Resource Community
Welcome Guest
  • Good evening, Guest.
    Please log in, or register.
  • November 20, 2018, 06:50:54 PM
Home Forums News Downloads Login Register Advanced Search
* * *
DragonPrime Menu
Login
 
 
Resource Pages
Search

Pages: [1]   Go Down
  Print  
Author Topic: accounts table...  (Read 3755 times)
0 Members and 1 Guest are viewing this topic.
aSeekr
Guest
« on: April 02, 2004, 04:22:45 AM »


I'm having a problem with the accounts table:
I am trying to update a set of records of which the current user's acctid is in the update.
All records get updated apart from the current user.  It's because saveuser is being called in the page footer and overwrites the update.
I have gotten it to work by separately updating the session information with the update but I'm not happy with this solution.  I could move saveuser, but again, not an elegant solution.

I briefly played with transactions but it's effect will depend on the DB being installed right on the server - and therefore not as portable as I'd like.

Any suggestions?

Dasher
Logged
lonnyl
Guest
« Reply #1 on: April 02, 2004, 05:03:52 AM »

I am not sure as to where or what you are updating.... although I have found that I have trouble updating myself with a module I am working on.  (aka, the person running the module)  I am going to add into it (when I get a chance) a check to see if I am working with my own record, and in turn do the db changes with the $session variable.  A little more info on your circumstances would help us troubleshoot a little better for you.
Logged
aSeekr
Guest
« Reply #2 on: April 02, 2004, 05:11:13 AM »


Doing the same, updating the accounts table and the person running the script is in the list of updates.
The same thing would happen with the sql:

update accounts set gold=10 where acctid in (x,y,z)
where the current user is x.

The problem is due to saveuser() overwriting the record with the current data.  I was thinking about a dirty flag in the $session['user'] field, and stop saveuser getting called if there are no changes.

That would also reduce impact on the DB generally if nothing had changed (such as doing a chat refresh).

Dasher
Logged
lonnyl
Guest
« Reply #3 on: April 02, 2004, 05:36:55 AM »

I was thinking in my case doing a compare of acctid and running a different little section that used simple $session[user][variable]= statements if the acctid check were true... just a few lines in the code and a nice simple workaround.
Logged
aSeekr
Guest
« Reply #4 on: April 02, 2004, 05:39:28 AM »


*grins*
That's what I have done at the mo.  The work around isn't elegant though.

I should look into transactions again I guess, that should fix it.


Dasher
Logged
lonnyl
Guest
« Reply #5 on: April 02, 2004, 05:40:22 AM »

I just did my change... looks like this...

if ($acctid==$session[user][acctid]){
   $session[user][job]=$job;
   $session[user][jobapp]=0;   
   }else{
   $sql2 = "UPDATE accounts SET job=$job, jobapp=0 WHERE acctid='".(int)$acctid."'";
    db_query($sql2);
   }
Logged
aSeekr
Guest
« Reply #6 on: April 02, 2004, 05:45:16 AM »


Make sure you enclose all array vars in ''

$session['user']['job']=$job;

Makes the code more robust, user can be interpreted as a constant rather than a string and I always separate vars out of inline string, again makes things more robust and easier to debug:

$SQL2="UPDATE accounts SET job=".$job.", jobapp=0 WHERE acctid='".(int)$acctid."'";

Dasher
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  


*
DragonPrime Notices
Play LoGD on Dragonprime

Support Us
No funds raised yet this year
Your help is greatly appreciated!
Recent Topics
DragonPrime LoGD
Who's Online
52 Guests, 0 Users
Home Forums News Downloads Login Register Advanced Search