LiveCode Forums.

Hi ppl,

I'm dealing with this stack field behaviour that acts as a local content storage...
While being practical sometimes this could create unsynchronized content with an underlaying DB.

First, I'm puling content from an Sqlite DB "Titles Table" in order to populate a List of Titles displayed as a DG.

A field from another table just contain long Descriptions that are also pulled out from a 2nd Description DB Table.
(Both tables share a common field value)


Each time a user click on any Title it retreives and populate the Description field below with a related content.

Since the Description content is left editable (on purpose), it can be modified at any time by the user...
- How could one force an update process towards the Sqlite content so that any time a content is being modified,
the Sqlite DB will be syncronized behind transparently, after the edit process is ended. (or meanwhile ???)

I am worried that a user could decide to click an App menu button "X" and instantly quit an App probably leaving its new content in the Stack field but an outdated content (unmodified yet) in the DB !! ...and this newer extra content will probably be overwriten the next time that its corresponding title is called again.
Any prooved method to deal with this event ?
Tks
Terii

Hi Terii

Not sure i fully understand but have some comments (off the top of my head -- no guarantees )

• if the correspondence of titles to descriptions is 1 to 1, then you should not be using 2 tables for this, should be just 1. Or does 1 title have multiple descriptions?
• You'll probably want to load titles and descriptions at the same time; store them in an persistent array (a script or global variable, custom property etc). That way you don't need to fire off a new query each time the user clicks a description (if i understood you correctly - apologies if not)
• I would probably recommend the on closeField handler to update the descriptions in the sqlite db if you want to do this without user action; when the user exits the field and it's text has changed it will fire of that message and you can use this to update
• You can update on closeCard - so the red x isn't an issue, it will update when the user leaves the card/quits the app. Only thing that will prevent this is if the app crashes i guess

does that help?

Hi Stam,
Thanks, yes, If onclose card and field do their job that would defenitely be my choice..when apps crash most anyone would expect to suffer some lost.
(maybe I can code some save to DB after n characters to limit even more those lost)

As for the rest, yes I'm leaving open a one Title to a many descriptions scheme - it has very interesting Pros, so I'm keeping titles/descriptions splited in two tables most likely. Each Title being just 1 record, it will always benefit this table loading speed !
As of now, firering a description query is an instant process (1 to 12 ms) ...being very few lines in both table.

I'll grab more dummy data latter on to measure more load lags...
Thanks again for the commands - testing this right now !
Good coding !

wuuuhuu, the on closefield was coded in a really smart way, only trigged if st has been changed !
very cool !