I have a webapp with Spring. I connect to the DB via JDBC. My issue comes in the following workflow:
I insert some testing record to the DB with the app. I see in the app and in SQLDeveloper (same query) that the record gets inserted. No problem.
I delete that record from SQLDeveloper. I see in SQLDeveloper that the record gets deleted. No problem
I go back to the webapp and refresh the page. Problem: the deleted records are still there!.
I'm sure I'm using the same query in the app and in SQLDeveloper (this is the only instance when I don't see the same in both environments). I tried restarting the app, but I can't imagine what else to do. Is there any cache system in Spring that could be causing this?
I can post some code if it would be any help, though I doubt it...
I suspect that you haven't committed the result of your deletion in SQLDeveloper, so you see your deletion in SQLDeveloper (same transaction), but not anywhere else, because those are running in different transactions.
EDIT: To commit, you can just execute the command commit; in SQLDeveloper, or hit the commit button at the top of the query window (a DB icon with a green tick in front of it)
Related
Using react-native-sqlite-storage for the first time, I was able to create an sqlite db file in the Android emulator, created a table in it and inserted a row successfully. After that on a button click, I also verified by a select that the row was inserted.
Then I used Android Studio's "device file explorer" to locate the test.db file in the data\data<apppkg>\databases folder and used "save as" to copy it to the PC's folder. Now when I open the test.db file in the browser utility, it's empty! There is no table in it.
Suspecting a "flush" problem, I also tried a db.close() in the app. But still I'm not able to get the populated database copy from the Android emulator. What am I doing wrong?
Update: I noticed that on the android emulator, there are 2 more files with the database file--an shm and a wal file. Reading some other threads, it seems they are keeping the journal so it seems the data is not committed yet. Those threads mention closing the cursor. But there is no such mention in the storage library docs. How do I ensure a cursor close from the App other than calling the close() that does not really close it and commit the data.
Finally, for my simple, single table requirement, I ended up calling executeSql on the db object instead of doing it through a transaction. That solved the problem and on close, it's always a single file. Somehow, when you use a transaction, the other files linger around even if you close the db.
I have an SQL file containing several commands, when I need to make a correction to my application database that the application can't yet do, I use DBVis to select and execute the command I need (e.g. to delete an incorrect entry). Problem is, the button to run the whole page is right next to the button to run a selected command. So I just dropped and re-created my table, losing all my data. Is there a way to undo this?
I'm looking to either 'undo' each command until I get back to the right place, or revert back to yesterday, where I know everything was correct.
Thanks!
Yes, you can if...
your administration tool did set autocommit=OFF by default, you can
just execute a ROLLBACK (or just shutdown your administration tool)
If latter doesn't work, check if your binary log was enabled, and restore with mysqlbin log tool
If none of the above mentioned solution works, use your (probably not existent) backup for restoring
I'm running a process that updates flags in a SQL Server database table. Essentially, the graph reads a .csv file, then uses the variables in the update statement. The universal reader is completing but the DBOutputTable component is hanging and won't complete. The funny thing is that earlier in the graph there's another DBOutputTable component that does almost the exact same thing and finishes successfully. Does anyone know what the issue could be?
I've restarted the services and the server itself. This process typically completes without issue but it just started hanging a few days ago.
I would guess non existing or not sufficient index on that table. That would manifest after a while, with larger data set.
Double check that previous DBOutputTable is doing update on same fields.
There is a postgresql installation on my server that worked fine so far. However now there is a single table (all other tables work fine) which I cannot open through pgadmin3 or drop.
I've tried restarting the server. Didn't help. I also tried dropping the table with DROP TABLE from the command line on the server. It's just stuck. I've executed the command and it has been just hanging in the console for the past hour.
I don't know what to do. Is there a file I could erase in the data directory perhaps?
Most probably explanation: some other open transaction is holding an exclusive lock on the table.
You are using pgAdmin, so you can check with Tools -> Server Status. The activity pane lists all current connections. For instance, there is one (or more) listings for every open SQL window. Look for long running connections.
You can also try to issue a DROP TABLE and check this list. With any luck you'll see what blocks it. Once you have identified the troublemaker and made sure, it's not needed, you might be able to kill the process. Might be vacuuming gone haywire because of bad settings ..
That, or something is seriously broken.
You could try taking a dump of the database and see if that works? Also have a look at the http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html#GUC-CLIENT-MIN-MESSAGES and log_min_messages options. Change that to debug and see what is happening when you try to drop the table.
In Case of Windows Users. Try restarting Postgresql by follwowing these steps: Start -> Run -> (then type in:) services.msc. Select Local postgresql Server and then press "Restart." Now, go ahead and try deleting the database or the table you wanted to delete (Via pgAdmin). Hope it helps.
I have just done a quick search and nothing too relevant came up so here goes.
I have released the first version of an app. I have made a few changes to the SQLite db since then, in the next release I will need to update the DB structure but retain the user's data.
What's the best approach for this? I'm currently thinking that on app update I will never replace the user's (documents folder, not in bundle) database file but rather alter its structure using SQL queries.
This would involve tracking changes made to the database since the previous release. Script all these changes into SQL queries and run these to bring the DB to the latest revision. I will also need to keep a field in the database to track the version number (keep in line with app version for simplicity).
Unless there are specific hooks, delegate methods that are fired at first run after an update I will put calls for this logic into the very beginning of the appDelegate, before anything else is run.
While doing this I will display "Updating app" or something to the user.
Next thing, what happens if there is an error somewhere along the line and the update fails. The DB will be out of date and the app won't function properly as it expects a newer version?
Should I take it upon myself to just delete the user's DB file and replace it with the new version from the app bundle. OR, should I just test, test, test until everything is solid on my side and if an error occurs on the user's side it's something else, in which case I can't do anything about it only discard the data.
Any ideas on this would be greatly appreciated. :)
Thanks!
First of all, the approach you are considering is the correct one. This is known as database migration. Whenever you modify the database on your end, you should collect the appropriate ALTER TABLE... etc. methods into a migration script.
Then the next release of your app should run this code once (as you described) to migrate all the user's data.
As for handling errors, that's a tough one. I would be very weary of discarding the user's data. Better would be to display an error message and perhaps let the user contact you with a bug report. Then you can release an update to your app which hopefully can do the migration with no problems. But ideally you test the process well enough that there shouldn't be any problems like this. Of course it all depends on the complexity of the migration process.