PS: I'm putting the Open Database in the Initialize and the Close Database in the BackPressed methods.
When I try the App, it gives me the error no such table: materiais (is one of the tables), indicating that the table does not exists.. And the message appears for all tables which were already created in the Screen1.
SQLError - is it asynchonous, somehow? Or the 'when simplesq error makes an error, everyone suffers.
By having load of labels on my screen and writing the states of variable to them in sequence as the code works, what it appears to be showing is that the code that runs if an SQL error occurs doesn't run immediately after the SQL command itself, like an interrupt, but appears to run after the end of that block, before control is handed back to the screen.
It definitely is running, but it seems too late for the information to be of any use to the code that runs immediatley after the SQL command, which is to check the content of the SQLerror message for any text that matches particular strings. ie, PRIMARYKEY or CONSTRAINT_UNIQUE. What I'm finding though is that the variable containing the SQL error message is empty despite being in the 'When simplesqlite1.ERROR' block - until afterwards. I'm not an expert on all the blocks, but I've looked at the ones I know how to look at, and I can't yet see a way of inserting the code to run when an SQL error occurs into the main block of code I want to execute so that it picks up the error immediately after I've tried to run the SQL command. Am I missing something obvious?
With regard to the SQLError event, this will ONLY fire if the runSQL command fails for some reason.
I am not sure that your variable would update in the middle of your "Add" event, in any case. You may need to move some of the blocks to the SQLError event.
You may need to branch your blocks: 1. No error (in Add event) 2. Error (in SQLERROR event)
'Validatecontextfields' is a subroute / procedure that checks the individual fields for their own validity before trying to create a new record (also will be used for checking fields prior to updating an existing record). It just checks fields for length and content validity so it doesn't create a record that has inherently invalid content. It doesn't do any SQL commands or refer to any SQL error message field in it.
I was intending to rely on the attempt to add the record and have the SQL constraints (duplicate key or duplicate description field which are already defined in the database) prevent an invalid record being written because, which does work. It's just that the feedback from that isn't available until the block containing the SQL command that has failed has completed in its entirety. I was wondering if it's a timing issue with an asychronous element to the error message handling, or if I am forced to it a 'proper' way of checking for existing records with identical fields and getting the response back from that before issuing the 'INSERT' command.
what this shows is that the label7.text is set to label1.text,as the last action of the block that includes attempting to insert the new record into the SQL table. This is after it has reloaded the table view file, which for testing purposes also loads the whole of the list into label1.text. However, Label1.text itself, just below the tableview table, is showing the SQL error text, which means it is not updated with the SQL error text until after the end of the whole block of code that executes the SQL instruction from which the error originated. So is there a way of getting access to that error code immediately after the SQL instruction that causes the error?
If I remember correctly, and from a quick look at the underlying code, you get one of three responses from the runSQL block:
If making a Create/Update/Delete command, you get back "SQL command completed"
If making a Read command, you get back the data as an array (unless there is no data, in which case you get the above string)
If an error, then you get back nothing.
You can test for this in your Label3 content, and then run more blocks depending on the returned value, branching to the SQL Error if response is blank.
Ensure your set Label3 to blank before running the SQL.
Hmmm, are you quite sure that the return result is blank or something other than 'SQL command completed' if the command fails? It's looking to me as though I'm getting that result even when it fails to insert a record.
Hmm, thanks for the suggestion. That feels like an unnecessarily complicated way of getting at it though. Would it take much to fix that so that it doesn't return 'completed' if it didn't carry out the command? Does the Tom Bennedum's version have the same problem I wonder?
