Hi Alex,

it sounds like db.Close() did not happened.
You should close db to remove the journal.


btw, did you enable V4RB log file?
if yes yo can see easy all V4RB function calls,
so easy can be found if db.close() was called.

Ruslan,
I apologize if I did not explain myself very well. Yes, the application did not call db.Close() because this was an abnormal termination of the program either because of stopping the debugger manually or a crash of the application. I guess my questions are really:

1. Why does it need a rollback if only read-only Client queries with no locks were made to the Database. Shouldn't the Database be in a guaranteed valid state as no data could possibly have been updated?

2. If a rollback is needed, how can I do this programmatically? I don't want to rely on the end-user to open the file in Valentina Studio to do a rollback. As much as I will try to prevent it, I know the application will someday crash for the end-user and I want to understand how to deal with this in as seamless and reliable way as possible?

Does this make my questions any clearer?

Thank you for your time. I worked with Valentina in the early 2000s when the product was the only decent solution for RealBasic. I am now upgrading a customer application that has been in continuous usage for more than 15 years, and they have been very happy with Valentina. I have to say that even that early version of Valentina DB it was using was very reliable. Valentina has had with much less problems than I had with other more mainstream Databases. I am looking forward using version 10 of Valentina and seeing how it works.

My understanding is that the rollback is automatic when you (the user) open the DB again after the crash, with your application or an other (Valentina Studio). This information is stored in the .journal file that is still staying near your db files (not deleted because not closed properly).
Just before you open the db again, you can test CheckRollback to see if you will have the rollback. It's up to you to let Valentina do this or make some additional before, such as backup the DB for example. That's what I do each time the db is opened (and in server mode, it is the first connexion) and the .journal file is still there.

Note that with earlier version of Valentina (5.8), sometimes I encounter a locked/blocked .journal file. And the DB or the server could not use it anymore unless you delete it yourself. Sometimes in this case, Windows say that this file is in use by the system and you have to restart the computer to solve this issue. If you don't delete this file and have some crashes again, the db could be corrupted (seen that with Varchar fields). (Sorry Ruslan/Ivan, not related on Mantis since 1) I cannot reproduce it and 2) It's an old version, but had it more than once).
In the current version (10.x) I had not seen this problem.

What you are saying is what I would expect in an embedded DB app. Unfortunately, my app is crashing on VDatabase.Open() if there is a rollback indicated from CheckRollback(). It opens just fine in Valentina Studio, and rolls back correctly. If I understand you correctly, it seems that crashing when there is a rollback needed is NOT what other users are experiencing. This is an older application that was written for version 1.0 of Valentina DB structure and the original Realbasic that I am upgrading to current versions. This app uses Child classes of VDatabase and VTable. I will be testing to see if the child classes are some how the problem.

If anyone has an idea on why this may be occurring, I would appreciate any help.

I just finish porting an app using v5.8 to v10.3 in Xojo 2019r1.1. I use Valentina since v1 too.
Of course a crash doesn't have to appear when open the db and rollback.
But perhaps it's the previous crash that have corrupted the database.

Some suggestions :
1) What happen if you trash the .journal and .ind file and next open the db ? Is there an error ?
2) Do you track VException (try-catch) during opening the DB
3) I suppose that saying child classes you mean subclasses. I use this way too. Check the constructors seeking errors there (had problem with 10.3, but it's not your version)
4) Set property Warning to True in the very first step. This will log informations in a Warning file (see in the vlog folder). Don't remember if there is a Verbose property as in the server version, but if so set its value to 3 and test yourVdatabase.open

In order to set the warning mode property in local mode, this is my code :

Valentina.Init( inCacheSize, "", "", "" )



dim VC As VConnection

dim i As Integer

VC = Valentina.GetLocalConnection()

if VC <> nil then

  VC.Open

  i = VC.SqlExecute( "SET PROPERTY WarningMode TO TRUE" )  // local only

  VC.Close()

end if

More information in the link below.

Well,

1. Indeed, Db.Open will cure the db itself if needed. It does not depend what app to use - vStudio or some ADK like V4RB.
2. Indeed, you can test CheckRollback to see if you will have the rollback to make some additional steps specific to your app.
3. I guess you are using "class-way"/"static-way" approach (specific to V4RB). Currently, I don't see how it could affect the restoring db from the journal, but obviously it is the only difference between your app and vStudio. So you can try following (at least as a workaround):

If CheckRollback is true - just do the "usual-way" db.Open - without defining the classes before (see any V4RB example except the "Class-way" one).
After that call db.Close, and finally, get back to your "class-way" style.
I think it should be working - please confirm that.
And one more thing - could you prepare and send me some test project to reproduce this issue?

Crash logs may help as well. Thank you in advance.

Sorry for the delay in responding to the above posts. I appreciate all of your responses. I did a more careful examination of how the subclasses were defined and found some issues in the code. I found that the VVarChar field was converted to VText for larger max sizes. Also some of the default parameter values for the constructors either have changed or were wrong in the older code. Also, the database on disk had more indexes defined than I was indicating on the constructors for the VField subclasses. Once I went through all the classes and fields one by one and made sure the VField subclass constructors matched the attributes shown in Valentina Studio for each field and table, most of the instability issues appeared to have been resolved. It is now working more like I had expected.

The unusual aspect of the issue and what was most confusing was that most of the application worked just fine with these bugs most of the time, but occasional instability on updates or deletions occurred that crashed the application. It would be nice to know when the subclasses are not constructed with parameters that match the database structure on disk when the file is opened. I was incorrectly expecting a VDatabase error, warning, or log file entry (or a more clear one if there is already one) if the object constructed didn't match the database on disk.

Once again, I thank everyone for their time and effort in responding.

I meant above that the V1 database had VVarChar fields with a large maximum size of 2048 bytes, and the converted database (converted with an older version Valentina Studio) had those fields converted to type VText.