Nope, that was just a silly and very wrong argument.
1 Like
I’m getting a strange crash in my database app that uses postgres and sql-light for local lookup tables. I updated to 2.0 then 2.1 from a much earlier version which required a re-write of all my buttons which are images. I put an exception trap on the end of every method that could fail. It could well be this sql-light issue and not my rewrite of the image issue. How does the gremlin manifest itself?
Please make an new topic. Then post your code and the crash log.
2 Likes
Although agreeing with Beatrix, but as requested, I inform you that the gremlin manifest itself as a SQLITE error 100, that, to be true, is not an error, but an internal code the user should never see, it is intended to tell to the engine dev, not the SQLITE user, that “the query was partially processed ok, you must ask the engine to process more steps, until the processing ends” but instead of this, this status code seems prematurely passed from the engine to the caller (us) as if it was an error, and probably the query never completed correctly.
We never got the feedback on how it can be triggered, it just happens. It’s said as fixed for the next r3, and I hope it is, because in the FB report it is stated that the workaround is trapping it and ignoring it, and that would be untrue if a code 100 slipped prematurely to the upper layer. If this was what happened, the fix would be (at the engine level) keep going until it ends successively (code 101, or 0) or error (anything not 100, 101, 0). Stopping at 100 and accepting it as ok with whatever you got, is risky, and maybe presents incomplete data, or incorrectly no data.
If you are not receiving an “error 100” from SQLITE, your problem is not related to this gremlin.