I am using Xojo 2013 Version 1. I am trying to delete a record from a SQLite database. But I am failing miserably. Instead of deleting the record, it duplicates it for some reason.
Here is the code that I use:
command = "DELETE * from names where ID = 10"
namesDB.SQLExecute(command)
I am dynamically generating command. but however I change it it always does the same. Same result with or without quotes.
Any ideas?
The very first thing I would do is check to see if there is an error being generated.
if namesDB.Error then
dim s as string = namesDB.errorMessage
msgbox s
return
end
It will tell you if there's a database error and what the error is. If there's no error then the problem lies elsewhere.
FWIW, always, always, always check the error bit after every db operation. Unlike other languages, Xojo does NOT generate/throw an exception if there's a database error so it's up to you to check it.
Try calling Commit().
I just made a sample SQLite database with a "names" table, and this code worked fine:
db.SQLExecute("Delete from names where ID=2")
db.Commit
I have done a lot of work with XOJO and SQLite, and they work well together. I have never seen a record duplicated erroneously as you report. That is very weird. If this doesn't help, post more of your code. For example, I assume your "command" variable is a String, but maybe it's a Variant, etc.
I think on SQLite you don't need the * between the DELETE and the FROM.
Related
DELIMITER //
CREATE PROCEDURE dbo.CleanupBackupRepositories ()
MODIFIES SQL DATA
DELETE HISTORY
FROM BackupRepositories
BEFORE SYSTEM_TIME DATE_ADD(CURRENT_DATE,INTERVAL 1YEAR);
//
DELIMITER;
i am trying to delete old history from this table but i get an syntax error on the line :
BEFORE SYSTEM_TIME DATE_ADD(CURRENT_DATE,INTERVAL 1YEAR);
every example i have checked tells me to do it like this? thanks for your time and effort!
There is a missing space between 1YEAR.
You also might want to use DATE_SUB as DATE_ADD results in 2022-08-12, not 2020-08-12. The way it is now, it would effectively wipe out all the history.
I'm converting a FoxPro database to SQLite, and migrating the instructions to update, where I found a problem.
If inside FoxPro I use Update Fact01 set Motivo = 'asdfgh' where TipoDoc='FV'
the rows are not updated.
But if I use Update Fact01 set Motivo = 'asdfgh' where TipoDoc Like 'FV' the rows are changed.
If I do the first instruction inside the SQLite engine, the rows are also changed. The field type for TipoDoc is NChar(2).
Also, If i do a select * from Fact01 where TipoDoc ='FV' statement inside Foxpro it works OK.
Any idea what's happening here?
I'm not sure if it's due to the fact that Nchar can store unicode data or the way data in general is stored. Wrapping an ALLTRIM around the WHERE clause may correct the problem.
Update Fact01 set Motivo = 'asdfgh' where ALLTRIM(TipoDoc)='FV'
This happened to me because i stored the column value as a BLOB instead of TEXT. Turns out the BLOB value is less than a TEXT value so LIKE found matches but = did not. you might be having the same issue.
I am new to robotframework and I am trying to get the hang of the keywords of DatabaseLibrary. I am getting error at 3 of such keywords.
1) I am using rowcount keywords as below-
${rowCount} Row Count <sql query>
And I always get ${rowCount}=0 irrespective of the number of rows in my table.
2) I am using Delete All Rows From Table as below-
Delete All Rows From Table <Table_Name>
And I get ORA-00911: invalid character but if use the same table with other keywords like Query ,it works fine.
3) I am using Table Must Exist as below-
Table Must Exist <Table_Name>
And I get ORA-00942: table or view does not exist but this table is very much there.
Please help me find what am I doing wrong.
Thanks in Advance!!!
I could be wrong but I believe a colleague told me there were issues, at the very least with the Row Count keyword.
However, for all three options there are easy solutions, which you've even hinted at in your question by using Query or Execute SQL Script
1)
${result}= Query Select count(id) from table
${rc} = ${result[0][0]} #Play with this as I forget exact syntax
2) Put your delete script in a test scripts folder with your tests and call it using Execute SQL script. You could also use Query to perform a select query before and after to confirm expected states.
3) Again perform a query against the table you're expecting to be there, a simple row count on id would do for this purpose. You could set a variable based on the result and use this again later if required.
I had similar issues.
I use cx_Oracle.
With the Table Must Exist keyword my problem was the same.
I dont really understand why, but first I have to use Encode String to Bytes keyword.
And I need to use a DatabaseLibrary 0.8 at least, because earlier versions didnt have solution for cx_Oracle. These solved this issue for me.
But with Delete all rows from table I still have problems.
Because this keyword puts a ; at the end of the line and it passes on that line to execute query if I understand weel, so it still causes an ORA-00911 error for me.
With Execute Sql String and the command DELETE FROM tablename you can have the same results, but it will work this way.
I hope it helps a little
I'm using the following command to update a field in my database:
UPDATE Movies SET 'From'=2 WHERE 'Name'="foo";
I'm using sqlite3.exe in windows (command prompt). Although no error message is produced, nothing changes in the table. I examined the database with a couple of gui tools and I'm sure UPDATE does nothing.
'From' is of type integer and 'Name' is text.
The problem you've got is that you're getting your quoting wrong. SQLite follows the SQL standard here, and that specifies what quote characters to use: '…' is for strings, and "…" is for tokens (like special names used as column or table names). Sometimes it manages to guess what you mean anyway and compensate for getting it wrong, but it can't with the WHERE clause because that is syntactically correct (if decidedly unhelpful):
Swapping the quoting appears to work:
UPDATE Movies SET "From"=2 WHERE "Name"='foo';
Those aren't good column names. Both are keywords, best avoided, and not self-explanatory at all.
Do a SELECT to see how many rows match the WHERE clause in the UPDATE. If none come back, you have your answer.
Did you commit the UPDATE? Is auto commit turned on?
I have gridview, when I connect the sqldatasource and run the application, data from stored procedure is shown but when i switch to design mode, the schema does not loads in gridview. I need that schema to rearrange columns and for formatting purpose.
I never had this problem before, All of sudden it is a problem.
What I tried so far "Refresh Schema" brings up the dialog which list all the parameters I am passing to the storedprocedure. After I changed DBType for every single parameter, it still give me an error, says "check your connection and storedprocedure". While the storedprodure does run, shouldn't it automatically update the schema in gridview. I still have the default 3 columns of gridview.
Note: I may get around the problem by adding each column manually but I am doing this to fix problem in the page, in the first place, dont want to run again in gridview problem. This is a new page that I am building. Thanks
It looks like, Schema is not updated just from StoredProcedure because simple there is not enough information how many columns will be returned.
To work around this issue and sort of quick fix, do the following.
Copy the query from you stored procedure and change the SQLDatasource from stored procedure to Select statement. Run your select statement and finish. Notice that your schema will now be updated.
You can now set your SQLDataSource back to stored procedure and the schema will remain the same.
It also occured to me that when you run a stored procedure, the column names are updated in the query using the name 'Databound col0' 'Databound Col1' and so on
I am not sure sometime it does, sometime it does not. Right click on Gridview and click Referesh Schema does not work as it gives some error.
Along the lines of #hmd, when there is not enough info, especially if there is another perceived dataset being return, i.e you are doing something that returns blank or debug data (rows affected, etc.). A workaround for this is to put "SET NOCOUNT OFF" in the beginning of your procedure and then set it back "ON" again before you return the data. This is also a problem on SSRS.