Is there a delay writing to an SQL Database

---

Can someone advise if there is a delay in data being written to the database following a tableadapter.update(datatable) command?

I save transactions which are subjected to the above and then a listview is updated to reflect them.

As I work through all is OK and the transactions appear in view.

I then run a backup through my app using a backup object to do this and this reports all OK

I then close the app and re-open and as as I am in debug the database is empty.

I perform a restore through my app using a restore object and selecting the backup file I created previoulsy which reports all OK

The retore procedure calls application.restart to allow the app to initialise to the restored data.

The problem is quite a bit of my data in missing from the restore as if the last block I did prior to backup never actaully made it to the database?

I also rememeber noting that at times when the update method is performed the actual timestamp on the physical databse is not updated....until I close the app and return to the designer?

So does this mean then prior to performing a backup I have to somehow force the app to ensure it has written all changes to the databse?

Thanks

hi,

very loosely speaking, "updates" (as long as all operations) are always written to both data and log files..

log entries are immediately written in syncronous way, so that transactions can be later committed/rolled back even in case of a system crash... on the other side, physical flush to the database "data" files is performed at "scheduled" time (in async mode to boost underlying OS I/O activity and not to make the database service wait for completation aknowledge), that's to say at checkpoint occurrances...

but even if a crash occurs before the physical data flush to the data files, at next SQL Server start up the data will be recovered/rolled back (depending on completation and commit status of the relative transactions) when every and each database is started up, entering the "redo" and "undo" phases to check what still need to be written to data file(s) (to the actual tables) from the log file(s) analysing all active LSNs (log sequence number) in order to find what need to be serialized.. so, usually, you are not concerned with such a deal in your application if not in case of real disaster and database corruption as, again, even in case of a system crash the database, at next start up, must (and actually "is", if no corruption is on the air) recovered to a consistent state...

so, I'm guessing you are using the User Instance feature provided by SQLExpress..

I'm also guessing you set the "Copy to Ouput directory" property of your database file(s) to "Always" and that you took a backup of your "original" database and not the one you are interested in, that's to say the one you were working with at debug/run time..

is this the case?

regards

|||Hi, thanks for your explanation, this will prove useful.

I found out from another forum that when performing a backup/restore it is better to do it using the release version of the application rather than testing in the IDE!

Once I did this all worked well.