[RESOLVED] Authorisation problem with db journal file in system.DocumentsDirectory?

Other
#1

Hi.

I am getting a sqlcode=14 error on the phone that I am not getting on the simulator. This only happens if I try to use BEGIN TRANSACTION … END TRANSACTION. So when I am trying to influence the commit rate by using the transaction mechanism in SQLLITE3, I receive this SQLCODE=14, but only on the phone!

I know the journal file is created in the same directory the database is in, which in my case is the system.DocumentsDirectory.

It looks like the operating system on the phone is not able to open or create a journal file in the system.DocumentsDirectory.

I found some information via this link: http://www.pantz.org/software/sqlite/unabletoopendbsqliteerror.html

It seems to me that the authorisations in the system.DocumentsDirectory should be sufficient, as the operating system is able to create the database file there and update it.
 

The whole APP is functioning fine, until I try to  start influencing the commit rate!

Nevertheless, is there a permission that needs to be set to solve this issue? Is there something else I need to do to make this work?

Any suggestion to solve this issue is welcome.

#2

According to the SQLite site:

SQLCODE=14 is #define SQLITE_CANTOPEN 14 /* Unable to open the database file */

So it sounds like it can’t open the actual database file.  I had another thread where the programmer had hand created the database in the system.DocumentsDirectory with the command line sqllite3 option on his Mac assuming that it would get carried over to his device and the contents of the sim’s system.DocumentsDirectory does not copy over.

#3

Rob. Thanks for the response.

The database is created by the APP, if no database exists. If I throw the switch that controls the commit rate in my APP, and thus don’t use the BEGIN TRANSACTION and END TRANSACTION statements, the whole APP is working fine, including the creation of the database.

So the only difference is the usage of the BEGIN TRANSACTION and END TRANSACTION statements. It seems very unlikely to me that because of the usage of these keywords in the SQL statement the APP receives a SQLCODE=14 on usage of the databasefile itself, as it has no problems if I do not use these keywords.

As you saw in the original message, there is someone who had exactly this problem (on a server…), and was appearantly able to solve it setting the correct authorisations for the user executing the statement containing BEGIN TRANSACTION … END TRANSACTION. I think he is right in thinking the error message is somewhat unclear and talking about another database file: the db journal file.

#4

I withdraw this topic.

I have created a testprogram to test this, and that is working fine. So it must be in the code of the original program somewhere.

Thanks for you patience!

#5

According to the SQLite site:

SQLCODE=14 is #define SQLITE_CANTOPEN 14 /* Unable to open the database file */

So it sounds like it can’t open the actual database file.  I had another thread where the programmer had hand created the database in the system.DocumentsDirectory with the command line sqllite3 option on his Mac assuming that it would get carried over to his device and the contents of the sim’s system.DocumentsDirectory does not copy over.

#6

Rob. Thanks for the response.

The database is created by the APP, if no database exists. If I throw the switch that controls the commit rate in my APP, and thus don’t use the BEGIN TRANSACTION and END TRANSACTION statements, the whole APP is working fine, including the creation of the database.

So the only difference is the usage of the BEGIN TRANSACTION and END TRANSACTION statements. It seems very unlikely to me that because of the usage of these keywords in the SQL statement the APP receives a SQLCODE=14 on usage of the databasefile itself, as it has no problems if I do not use these keywords.

As you saw in the original message, there is someone who had exactly this problem (on a server…), and was appearantly able to solve it setting the correct authorisations for the user executing the statement containing BEGIN TRANSACTION … END TRANSACTION. I think he is right in thinking the error message is somewhat unclear and talking about another database file: the db journal file.

#7

I withdraw this topic.

I have created a testprogram to test this, and that is working fine. So it must be in the code of the original program somewhere.

Thanks for you patience!