Creating a database for mobile journal? - Solved

[DR White]

I have never written a database type app before. I want to write a simple mobile journal.
Each entry consist of 9 elements - DataEntry[tDate,tEvent,tSubEvent,tLocation,tSubLocation,tActionTaken,tComment,tExtra1,tExtra2].

How do I make a database "Record" that will be stored in a file on a phone?

Would anybody be interested to point me in the best direction so that the user can search the data entries based on any of the 9 elements.

I was thinking that there was some kind of special encoding used to save arrays?

What is the best way to search for a data entry based on matches of the 9 array elements?

Thanks,

David

[DR White]

I believe that a data grid will work for my application.

[simon.schvartzman]

DR White, have you seen the lesson below regarding working with DBs?

Should be a good starting point

https://lessons.livecode.com/m/4069/l/5 ... e-database

[dunbarx]

Hi.

Not that there is any reason not to use an array, but is there any compelling reason to?

Searching a dataSet, whether an array or simple delimited data, is straightforward. My real question is this, are you concerned with the mechanics of an actual database, or really just talking about searching through data?

Craig

[DR White]

Craig,

It will be a Searchable Troubleshooting Journal.

It will be a tool for electrical technicians to build a knowledge base on the phone for problems they encounter.

I just started yesterday and I thought I would try to use "Best Practice", before I hack a way of doing it (the way I usually do things).

I attached what I think the data entry page might look like.

Thanks for responding,

David

[Mikey]

I tend to think of everything as a DB, and I tend to use db's no matter what, but I have a feeling that for someone who has not implemented one, before, it might be overkill for you for your first mobile app, especially since DB's (generally) require learning SQL and some of the vagaries around parallel data structures (tables).
You absolutely can do it, and if this is intended as a learning exercise for yourself, by all means, jump in, but understand that there is going to be double the learning overhead for this first one, even before you get into the finer points.

[DR White]

Since in most cases the number of entries (records) will be less than a 1000, maybe I can use a simpler array file. Any guidance will be appreciated.

Thanks

[bogs]

Well, I don't know enough about mobile to say this would work there, but, if I were doing this on a desktop with a 1000 or so records, I'd just use cards themselves. 'Find' works pretty good for the simple task limits you set forth.

[Mikey]

Searches on mobes and on SSD's on desktops are so fast that I'm not sure your dataset size will matter.
Maybe the first thing you should do is make a test worst-case container, with, say, 5000 lines in it, delimited by commas or tabs, or whatever you choose.
Try searching the container for something, e.g. "A/C"
Basically the goal of this test is to write your search algorithm in classic LC code.
Is it fast enough? Does it do everything you want?
If the answer to either of those is "no", then maybe a DB is appropriate, and we move on to learning about databases.
If the answer is "yes", then maybe using a flat file or the HC approach with just a bunch of cards will be good enough.

[jacque]

If you want to use an array, you can store it on disk with arrayEncode. To read it back into usable format, use arrayDecode. Searching an array requires looping through all the elements but it's very fast.

A plain text file would also work and you could use any of the offset commands to search, which would also be very fast.

I agree that using a database for the first time would be a steeper learning curve.

[DR White]

Jacque,

I have used arrayEncode before (I think you suggested it on a previous app) and it worked well. I think it is a good suggestion for this app as well.
I just wanted to be sure that I wasn't overlooking a better method.

Thanks for everyone's help,

David

[dunbarx]

The suggestion to use 1000 cards is sound in theory, but know that LC starts to slow noticeably after about 3000 cards.

I have stored similar data, and loaded in as needed onto a single card. The user cannot tell the difference, even if you want to include special effects every time you update.

Craig

[Mikey]

Good tip.
There are so many ways to skin this cat in LC.

[mrcoollion]

Take a look at post viewtopic.php?f=12&t=33338
Here is a stack that enables you to save data in an array and retrieve it including encryption.

Regards,

Paul

[kdjanz]

DemoSaveAppData.livecode.zip

(2.76 KiB) Downloaded 126 times

With all credit to mrcoollion, I have modified his stack to make it a little more modern.
All the fields now use a behaviour script for their functions, so all the code for all the fields is in a single spot for modifications. This also means that if you clone a field by dragging it with the option/alt key, it keeps the behaviour settings, so that field is saved automatically as well without having to script it or set it manually.

I also changed the save function to only save to the documents folder. When I tried running his stack from my downloads folder, no data was saved because the stack did not have permissions to write to that folder. All apps can write to the documents folder however, so this is a safer place to save data on desktop or mobile.

I changed the original Encrypt and Decrypt commands to be functions that returned the data to the caller. I just thought the code looked cleaner with function calls instead of commands with multiple inputs and outputs.

The guts and logic are still his, so credit still goes to him - although I'm stealing it for a ToDo app that I am working on now. I'm going to try to make it a script only library stack to add to my existing work. Never done that before, so learning is guaranteed to occur!