Ninox for Mac not responding

I've encountered those issues before. For me it was because I had too many select statements in my db. 

 

I have a sports league db, so you can image stats are a big function of any sports league. I started like most newbies by creating stat fields (based on select statements) in my raw data fields. Then I discovered dashboards, so I started creating more stat fields (still based on select statements). Then one day everything slowed to a crawl. Opening tables. Clicking on fields to edit. Saving changes. Transistioning between tables. Everything took a long time to do.

 

I sent my db to Ninox and they just said you have too many select statements. I asked how many is too many and got no hard number.

 

So how did I wean myself off select statements? By using relational links and dashboards.

 

If you are not familiar with dashboards here is a good starter:

 

https://www.youtube.com/watch?v=nUqGl84gh08

 

But the video shows using select statements, so how do you get around that. Nixous has another video that shows what they called "hyper dashboard", but it is only available to paying members. What the principle behind their "hyper" dashboard is now you link the dashboard table to everysingle record in your raw data table and now the dashboard has vision to everything.

 

For example if you had a table called rawData and a table called Dashboard. You would in rawData create a new table reference field to Dashboard, lets us call is toDashboard. Then you would make sure all records in rawData is visiable then select Update Multiple Records. Then select field toDashboard, select Assign constant value and then type in the Id number of the one and only record in your Dashboard table.

 

Now you can go back to your Dashboard and replace any select statement with a direct link reference. Before you would have:

 

let x := sum(select rawData[Field1 = 1])

 

That changes to:

 

let x := sum(rawData[Field1 = 1])

 

Once I swapped over my DB ran like before.

 

I hope this helps.

Hi Fred/JJ

Thats interesting - I did not know about the hyper dashboard video (but I do now!). I have been aware of the limitation of using too many select statements for a while and used the do as server statement wher i could to help speed up processing (especially on the dashboard where i am grabbing snap shot stats data.)

As a fully paying Ninox multi user subscriber, I will not contact Support to get the video info. 

This type of condition is not just limited to Ninox. for some 10 years I was plagued by sloooowdown with Dataease's 'select' and I could even get Access to crawl at times. My issue is that I am always going to have this situation in some form as my main table is now approaching 700k records and is constantly being accessed by several staff for stats info. Thus, I have resorted too many views that cut down the seletion process to help speed up. Without these the all records view takes some 1.5 minutes to even load! 

Mel

Hi Fred

 

I too was very interested in your hyper dashboard. I think you could have got away with calling it your own! Do you have a Trigger on create script to automatically link records to the hyper dashboard?

 

Mel - The same is true with FileMaker. It can be painfully slow, or lightning fast depending on the data architecture. I guess it's the same with all languages.

 

Regards John

I posted another data point showing the difference in performance between using the "select" statement and following the references in this thread:

https://ninox.com/en/forum/technical-help-5ab8fe445fe2b42b7dd39ee7/disappearing-formulas-60e5f4899657f774f0d68b0d?post=60e966b69657f774f0d68b93&page=2

@JJ, I too agree. I was peeved that I had to redesign everything because of the limitation that doesn't have a hard number to go by.

 

@John, as usual, you have figured out that I had to put a formula in Trigger on create to auto-link new records to my dashboards.

A new version (v3.5) is out with the following enhancements:

 

Smart caching
Improves the consequent loading time of table views and execution of select queries

 

and

 

Transactional scripts

A new construct do as transaction added to Ninox script
Behaves in the same way as do as server
Allows a set of code to run within the context of a transaction
On mobile apps, do as transaction executes on the client and thus allows for offline-capable transactions
Run the script within transactions to achieve faster execution and higher consistency

Either apply changes upon successful completion or discard changes if any of the code in the wrapped script fails

 

I haven't tried it yet.

 

Also we haven't mentioned cached() and invalidate(). I haven't used them but if your data set doesn't change much you can only make 1 call to the server to get your data.