There must be a better way to do this...

i am trying to setup a small scale banking system with my groupmates to help manage money but each person has thier own balance. so far what i thought up was just using a list

 [person1, person1balance, person2, person2balance] 

but this seems like an unsecure way of doing this, is there any other way that i might beable to do this? i havent really worked with lists much in my past scripts.

I'm a little paranoid about this myself. Where security is more important than performance I usually use multiple lists:

list customerKeys = [];
list customerBalances = [];

addCustomer(key cust, float bal)
{
   customerKeys = (customerKeys=[]) + customerKeys + cust;
   customerBalances = (customerBalances=[]) + customerBalances + bal;
}

removeCustomer(integer custNum)
{
   customerKeys = llDeleteSubList(customerKeys, custNum, custNum);
   customerBalances = llDeleteSubList(customerBalances, custNum, custNum);
}

integer getCustomerNum(key cust)
{
   return llListFindList(customerKeys, [ cust ]);
}

setCustomerBalance(integer custNum, float newBalance)
{
   customerBalances = llListReplaceList(customerBalances, [ newBalance ], custNum, custNum);
}

// etc.

This is somewhat less efficient in terms of both performance and storage, but it GUARANTEES you aren't going to accidentally find a name when you are searching for an e-mail address or whatever. In this very simple case you shouldn't have an issue because the keys and the balances are very different types (I won't trust their list functions not to so some implicit casting no matter what the Wiki says though, especially in a critical money application).

Well you may want to use two lists, the first one with their names, the second with their balances. You just want to be careful that if you add/remove names that you keep the order right or the balances might get shifted.

So somethinglike:

 list accounts = [person1, person2, person3];
list balances = [balance1, balance2, balance3];

Then to alter their balances or retrieve them you could just use the same index for getting the values out of or updates to the list. And there's not much you can do to make it more secure than that. By seperating the balances and the account names it means you are less likely to overwrite a balance when working with account names but you still run the risk of using the wrong balance if you have to remove an account holder (though maybe you could add a third list that has an active/inactive status so that rather than remove the account it just sets it inactive so it can't be altered, and this could also preserver the account balance).

It has a problem with a fixed number of maximum accounts/users, but another way I have done this kind of thing recently is to use a prim per account to store the values persistently in the description field. Have a central script coordinate the transactions through link messages.

This can get rather tricky though. I find that the more I worry about exactly how a script should react to all the possible events, the more I complicate things to the point of absurdity. Is a user really going to take an item into their inventory when it still owes people money and then rez it multiple times? Gah! Maybe, and I go to great lengths to try to protect against such hazards (for that particular case the only real solution is to alert the owner and not pay the money). YMMV.

EDIT: Probably I go to ridiculous enough extremes that it would be more worth it just to go through the effort of setting up an outside database somewhere.

Give us some kind of structure type (if not actual classes), LL! Please! LOL.

ok... first grazel, i really dont want to use lists like that because of the risk of transfered payments and hewee, i had the actual lists made so when they near max it starts a new list in another script. but i decided to with a xmlrpc communication with an outside computer (i am MUCH more expierenced in other scripting languages than lsl) so i am going to do it that way. which also means i can allow each person to store their money in catagories. thanks for all the help tho.