Standalone data saving - best file format?

[stephenmcnutt]

I've got a Mac/Windows standalone that saves data to .rev stacks (or stack files??). I believe this sort of file is old and probably not the best for saving standalone data. What IS the best method/file format?

I need to save not only parameters but an undetermined number of sets of quiz questions created by users of the standalone, so whatever I use has to be flexible to accommodate these newly created question sets. I just create a new card in the data stacks with my .rev data files.

What about .plist files? Is that something I can/should use?

[quailcreek]

Hi,
You could use a text file for simple data. A MySQL or SQLite database would be better. The pList is something totally different. What version of LC are you using? The .rev extension was replaced with .livecode quite a while ago.

[Simon]

I say stick with the stack method unless... you should be using a database (if you have 1k questions you might think about a DB).
Stacks are happy to hold binary data as well as text, really easy Get/Put, plus if it's what you are used too.
The extension doesn't matter as long as you use "start using stack" (and it is a stack) could be myData.dat.

Simon

[FourthWorld]

Stack files may be a good choice. But just to complicate things with more options encoded arrays can be useful too.

[AxWald]

Hi,

Standalone data saving - best file format?

Depends of the type of data, IMHO. I'd use:

• Text files, if there's just some few entries to remember, and if it's desired to be able to change them on the fly.
  Usually I name them "[AppName].pref", and often the values are encrypted.
• Since I do a lot of database work, I love SQLite. As soon as there's more but a few entries of table-like data I use an SQLite db.
• And for stuff like binary data, properties and handlers I use stacks. Nearly always I have a stack besides my StandAlones, with the basic logic in the SA and all handlers (& other data) that may change in a stack-in-use.

And often I have 2 or all of these besides my StandAlones ;-)

Btw.: It may be a ghost from good old HyperCard days, but I never store data on cards. My stacks rarely have more then 3 cards ... Bill Atkinson: "HyperCard is not a database" :)

Have fun!

[dunbarx]

AxWald.

Funny, I always stored data on cards, coming from HC, where it was not a burden on the engine to have 30,000 of them.

When LC came along, and the textEdit limit of 30K characters went away, I thought I was in heaven. This even though LC will slow noticeably after more than a few thousand cards. One day I will try an external text file, or SQLite, but only for the thrill of it.

Craig Newman

[jacque]

For things like simple text storage I use text files. But mostly I use stacks because of the many numbers of ways you can store things there. Data can be in fields or custom properties, and you can store object templates or behavior scripts easily. Data can be arrays, binary, html, UTF8/16 or anything else.

Richard used to advocate for stack storage passionately until he moved to arrays.

[dunbarx]

Code: Select all

Bill Atkinson: "HyperCard is not a database

He was astonished at the response of the world at large, where hundreds of thousands of people demanded detailed knowledge of every nuance of HyperTalk.

He likely might have privately reconsidered that quote, especially since there was no native SQL support in HC.

Craig

[stephenmcnutt]

Thank you all for the kind replies. It sounds like I should stick with stacks. Quailcreek, I'm using the latest version of LC, but I started my app over 20 years ago in HyperCard and rewrote it in LC/Rev when HC went legs-up. It's a game I made for my classroom when I was a first-year 4th grade teacher. http://www.classroomquizshow.com I work on it every once in a while when I want a new feature or get an idea for doing things more efficiently under the hood.

Again, thanks.