LiveCode Forums.

Heloo geniuses

Just want to ask a few questions as I am planning my strategy for new more complex sections of my app.

1. I have read in this forum, the the "for each element" or "for each key" are very fast, capable of handling many many records very quickly.

My plan is to store all data in an array and search IT, to display information. My SQL calls are to load and save data....BUT NOT search. Am I wrong on this ? .... my array may hold anywhere from 250 to really huge amounts depending on how it is used by the user, and how complex the situation is.

I plan on searching my array using "for each" command, searching the keys for matching values and then adding the found record into an array to be displayed on a datagrid.


2. Is it possible and is it SAFE to leave a "repeat while" loop going while the user is still using the app in other places or other screens and wait for a condition to be true?

I want to constantly check if a certain condition becomes true, it may take days or weeks and sometimes years of using the app to reach a condition. Or like checking remote connections every 5 minutes for synchronization.

I want my app to "ask itself a question ALL THE TIME" .... is that what the while command is for? and is there any problem with leaving a while loop running in the main stack? Other handlers should still execute correctly right?

and where would I put this loop? I would want the opencard and openstack handlers to finish right?

Thanks everyone.

and 3. Do Data grids require a the root key to have a numerical index? Is it different for setting the dg Data or setting the dg Text?

makeshyft wrote:My SQL calls are to load and save data....BUT NOT search. Am I wrong on this ? .

Yes.

MySQL can search at dazzling speed through huge amount of data. This is what databases are for.

Why would you want absolutely to do the search within LiveCode ?

The reason for this is that each user gets their own database of records, but these records interact with eachother......and I didn't want to construct a temporary database that would combine all the users databases into one giant one to search it. So my plan was to load all of them into memory AS ONE array. and read all the interactions from there including filtering and searching.

is that not a good reason?

wonder if the livecode dictionary is using sql calls for filtering..

Regarding 2.

Repeat loops should NOT be used as a constantly running thing. They are for looping through some data fast and doing something immediately on that data.

What you are describing is an Event handler type thing. The easiest way of doing this is to use the 'send' command with a timer:

eg. send "checkMyVariable" to me in 1 second

This could be activated in the openStack handler of your main stack. Within the function "checkMyVariable" (or whatever you call it) you simply put the same send line at the end - so that it calls itself again.


If the variable is one that is changed by some calculation based on some data changing then it would be better to simply put an if statement in the calculation part of your code.

Cheers,
Dave

PS. 1. Use the database for the search too.

makeshyft wrote:The reason for this is that each user gets their own database of records, but these records interact with eachother......and I didn't want to construct a temporary database that would combine all the users databases into one giant one to search it. So my plan was to load all of them into memory AS ONE array. and read all the interactions from there including filtering and searching.

is that not a good reason?

Okay, but still : i believe MySQL would be faster than LiveCode.

But you could perhaps go for a "dual" solution :

-a LC script that would send a search SQL query to each one for your XX tables and YY databases....and then just agregates the results, and displays the results.

How many tables /databases do you have in total ? And what is the volume of data ?

For the sake of the argument, have you indeed tried the big-all-in-one temporary database solution in MySQL ?

Another idea : instead of big-all-in-one database, why not an index table (on which you would perform the search) if your search are very narrow ?

You should give us more details about your DB scheme, it would help us to understand what do you want to achieve.

Ok... well.... thse are the main points that made me think of this strantegy

I am using SQL lite as a database for each user
Each user will only ever write in his/her database and only read that of the other users
(I did it this way, because using SQLLite I can read the same file no matter how many people are involved, and never run into problems with people WRITING to the same file at the same time.)
There could literally be 2 users or 50,000 depending on the size of the organization and the case being worked on.
The consolidating of data into one array would only happen ONCE on start, which is why I thought i could get away with "loading time".
Each user might have maybe 100 records that might be read, but sometimes, they may have 1,000+

I WOULD actually prefer using SQL to search and filter ... because I have experience with it. so I think I will be doing that, since reads are safe to do in SQLite and network environments.

I am not so much concerned with speed, but more concerned with a synchronization process that will ensure data integrity, and make the installation easy for organizations that will have lots of users.

Thanks Bangkok

and thanks Dave for answering #2.

I know this is an important decision, I am happy I took the time to write about it.

Cheers guys.