every now and again SDK becomes unusable...

[stamatis]

Hi all,

I've had this recurring issue in developing an app based on LiveCloud -- every now and again, without any clear triggers, the SDK becomes 'unusable'. I'm guessing there is a possible corruption issue?

I just get the message 'the CanelaDB SDK is missing' -- when it's clearly there and has been in use for weeks with no issues...

The SDK folder is stored in a folder containing the LiveCode mainstack; it uses a local DB that syncs with the cloud DB with a custom handler called SyncDB pSource, where the pSource is either local or cloud and will overwrite destination at cloud or local respectively...

This type of issue seems to crop up every 3-4 weeks, I'm unable to explain why... If i download the SDK again, it works but of course my concern is if this will keep happening with the deployed app...

Any suggestions?

[stamatis]

Hi LiveCloud team - this keeps happening every 2-3 weeks. 
"SDK not found" in spite this being in constant use for weeks previously.

I'm getting slightly annoyed at having to re-download the SDK every time this happens.

And also quite concerned as to why this is happening - is this something that is going to affect the standalone app?

[Jason Lam]

Hi Stamatis,

Is it possible that you can zip the project and email to support@canelasoftware.com so that I can diagnose the issue further?

Thanks,
Jason Lam

[stamatis]

Hi Jason, 
I’ve rewritten the app from ground up. So far no issues. 
What seemed to be happening is some kind of problem with the config file. 
At present the app is heavily in flux and probably will need another couple of weeks to make sense to others. If at any point this issue recurs I’ll freeze a copy and send it to you, is that OK?

Many thanks
Stam

[mark_talluto]

That is perfect Stam.

-Mark

[mark_talluto]

For everyone's benefit, turn on Variable Preservation in the LiveCode preferences/Script Editor/Variable Preservation = true

CanelaDB stores important information about your setup in script local variables. They can lose the values when you stop and edit your code. LiveCode developed the Variable Preservation mode to protect the content of your script local variables.

Give this a try and see how it goes.

[stamatis]

For everyone's benefit, turn on Variable Preservation in the LiveCode preferences/Script Editor/Variable Preservation = true

CanelaDB stores important information about your setup in script local variables. They can lose the values when you stop and edit your code. LiveCode developed the Variable Preservation mode to protect the content of your script local variables.

Give this a try and see how it goes.

That's not the cause of my issues; variable preservation is on by default i believe - or i switched on long enough ago that i don't remember doing it
Certainly this has been on all the time i've been using LiveCloud...

[mark_talluto]

Hi Stam,

In your direct emails, you mention the DataGrid. I am not strong with how the DG works in code. My first thoughts were name-space collisions. Our names are pretty unique, and I would guess Trevor's are as well.

We have an on libraryStack that moves the authkey from a global to a script local. This process is designed to run only once. But, if the libraryStack handler fires for any reason, the global value will replace the value of the script local variable.

This process works fine the first time it happens. But, the following line puts empty into the global. Thus, if the handler fires again, the value is replaced with empty. This conclusion would not be good.

We have code that verifies this handler is relevant to canelaDB, but for some reason, the variable management happens before the check. We will fix that.

In your code, I found that you have a line in stack "CoreLab3" (line 26) that overwrites the gCDBAuthKey. The contents are from the internal debug/logging variable we use. This new value from that line will break CanelaDB's ability to decode your config file. We will fix the output from cdb_auth() to not contain the log value. But, even if we empty it, you will introduce a new value into gCDBAuthKey. Ultimately, this is probably not the core of the problem, but worth noting. You might want to change that to: get cdb_auth(...). I would classify this as a documentation bug on our part for not pointing this out.

Let me get a new build of the libraries with both of these changes introduced. Your feedback on this will help us solve this mystery.

-Mark

[mark.h]

Hi Stam,

In addition to what Mark said regarding not resetting the gCDBAuthKey global, there is a second issue in play:

The canelaDB libraries are being libraried multiple times. This happens because in your mainstack stack script, the preOpenStack handler calls "initializeCanelaDB", which starts using the canelaDB libraries. If this occurs while gCDBAuthKey is incorrect, you will see the error that you saw.

The reason your preOpenStack handler is getting called multiple times is because you have substacks, and whenever those substacks are opened, a preopenstack handler is sent. The preOpenStack handlers aren't being explicitly handled by the substack, so they pass to the mainstack. I recommend one of the following:

1. Move your preopenstack handler out of your stack script, and into the first card of your stack
or
2. Update your preopenstack handler to check the owner of the target:

Code:

on preOpenStack
   if the owner of the target is me then
   initializeCanelaDB
  end if
end preOpenStack

or
3. Add an empty preopenstack handler to all of your substacks

I think 1. or 2. will work best for you, though I would also still recommend that you don't assign any values to gCDBAuthkey

[stamatis]

The canelaDB libraries are being libraried multiple times. This happens because in your mainstack stack script, the preOpenStack handler calls "initializeCanelaDB", which starts using the canelaDB libraries. If this occurs while gCDBAuthKey is incorrect, you will see the error that you saw.

The reason your preOpenStack handler is getting called multiple times is because you have substacks, and whenever those substacks are opened, a preopenstack handler is sent. The preOpenStack handlers aren't being explicitly handled by the substack, so they pass to the mainstack. I recommend one of the following:

1. Move your preopenstack handler out of your stack script, and into the first card of your stack
or
2. Update your preopenstack handler to check the owner of the target:

Code:

on preOpenStack
   if the owner of the target is me then
   initializeCanelaDB
  end if
end preOpenStack

or
3. Add an empty preopenstack handler to all of your substacks

I think 1. or 2. will work best for you, though I would also still recommend that you don't assign any values to gCDBAuthkey

Thanks Mark - this does sound like a much more likely culprit!

I've gone with (2) and changed 

Code:

initializeCanelaDB

to 

Code:

If the owner of the target is me then initializeCanelaDB

in the existing preOpenStack handler as that was the smallest change; so far so good - if that causes a similar issue again, i'll try (1)

thank you very much for your help!
Stam

---

Let me get a new build of the libraries with both of these changes introduced. Your feedback on this will help us solve this mystery.

-Mark

Thanks as always for your tireless work Mark.

So far the issue hasn't recurred, will feed back...

Best regards
Stam