Saving lists/databases?

Is there anyway to "save" a list inbetween a script reset? Im planing on making my own customer/Sales Tracking object, pretty much just have all my vendor send a message to the main "Server" on each sale, But if I wanted to edit it is there anyway to save a full list? or output it into a file...or somthing?

The only 100% bombproof way is the get the info out of the script. Either by sending it to an external database or simply having the script llOwnerSay the list so that you can paste it into a notecard for example.

I just finished a script that did the second part. I can select a menu option to say the list and I can also paste that info back into chat and say it back to the script.

Well you gave me a good idea with that 2nd part, rather then me doing it, have the object list everything off to another object via listen, then it could simply send it back to the main "Server" once the update of the script is done. Would be a nice way to make a backup of all the data. Hmm iv never really checked, if you put an object in your inventory are all its variables saved when you rez it again?

Yep, it will still be there!

In case you run into a problem, here is the script where I can say and hear the list data:

http://www.google.com/notebook/public/04649246122957173952/BDSeqSgoQlN3opqgj?hl=en

Parts of it might come in handy. You will notice that with a long list, you have to make provisions to break it apart to get around string length restraints.

My self made POS system emails after each sale, and once per day sends out a daily report (the single emails are for in case the script looses data sometime during the day). The daily report lists all sales, who bought what, how much they paid, and total sales for the day.



http://www.secondscripter.com/

You can also use the objects name and description to store info... And have the script read it back from there. I use that a lot

There's a limit on the description length though, Seemok, so that isn't good for large amounts of data.
http://blog.secondlife.com/2008/02/01/scripters-object-name-and-description-changes/

You can store the data in a separate script too. That way if you are editing the main script it can access the storage script without the storage script losing data. Taking that concept further, once your storage script is stable use an alt, or get a friend, to compile it and give it back to you for use in your objects, that way reset scripts in selection will only reset your main script and not the storage script.

I thought about doing this; Have my script output its current Settings to chat so that it can be copied/pasted back into a new settings card after an upgrade, but can you in code supress the time and object name from the chat, so that what you paste back doesn't have "[time] object:" first?

Bones

There's a trick you can use to neaten things up a bit. Have a look at the following on the wiki's LSL Portal.

http://wiki.secondlife.com/wiki/MySay

As for the time-stamp, you could always edit it out in the Notecard reader.

Brilliant, thanks for the quick reply.

I knew I'd seen this somewhere in the past but couldn't put my finger on it.

I can disable the timestamp in the chat options, so that's perfect!

Thanks.

very useful if you have multiple product scripts sharing an object.

and you can turn off timestamps in preferences if you like.

I do the same thing but I use an external MySQL database on a server. I've worked with the VK-DBMS system inworld, but the problem with inworld data is persistence. I'll eventually lose it due to reset or it will max out and fail. Either way I just wasn't willing to go through that, or the hassle of jumping through all the hoops to try to get it to be persistent inworld. Call me lazy lol

Yes, that is an issue with VK-DBMS. I deliberately left out memory testing as LL refused to fix llGetFreeMemory() in mono and the fact that they are/were still playing with the garbage collection. I could not get confirmation either directly or via tests as to how much data I could expect to safely handle and decided that the user would have a better idea of their own storage requirements.

Personally I use it in most of my projects because it simplifies list handling and, to my mind, makes the main script easy to read and maintain.
In most of my applications I have a reasonable Idea of how much data to expect, the only one that is unpredictable sends me a memory dump via email every 24 hours and has only fallen over twice from stack/heap collision.

As soon as an alternative to llGetFreeMemory is available I will update VK-DBMS to have proper memory management and so warn the user if the database is nearing the limits and stop accepting dbInsert commands for the sake of data integrity.