Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Hi Afriza, On Feb 1, 2011, at 4:16 AM, Afriza N. Arief wrote: On Tue, Feb 1, 2011 at 3:38 AM, Tito Ciuro tci...@mac.com wrote: Hello, The following code snippet runs fine on Mac OS X, but fails on the iOS simulator: // Obtain a path for the database NSString *docs = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject]; NSString *path = [[docs stringByAppendingPathComponent:@ myDB.sqlite]fileSystemRepresentation]; // Open the database sqlite3 *db = NULL; int statusOpen = sqlite3_open_v2( fileSystemRepresentation, db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_AUTOPROXY | SQLITE_OPEN_FULLMUTEX, NULL); Do you need UTF8String for the sqlite3_open_v2() ? I don't think so. The fileSystemRepresentation method should we used when dealing with file-based paths. This is because the length of the encoded string in foreign file systems can be longer than the number of Unicode characters in the NSString. So, you would end up with a different length (a wrong string) by using UTF8String. Regards, -- Tito ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Quoth Tito Ciuro tci...@mac.com, on 2011-02-01 09:01:09 -0200: I don't think so. The fileSystemRepresentation method should we used when dealing with file-based paths. But not when dealing with SQLite paths, unless I'm mistaken about what fileSystemRepresentation does. sqlite3_open_v2 always takes UTF-8 and does any filesystem-specific encoding transformations internally. (It may still be that it does it incorrectly on some platforms, in which case that may be a bug.) -- Tito --- Drake Wilson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Hi Drake, On Feb 1, 2011, at 9:33 AM, Drake Wilson wrote: Quoth Tito Ciuro tci...@mac.com, on 2011-02-01 09:01:09 -0200: I don't think so. The fileSystemRepresentation method should we used when dealing with file-based paths. But not when dealing with SQLite paths, unless I'm mistaken about what fileSystemRepresentation does. sqlite3_open_v2 always takes UTF-8 and does any filesystem-specific encoding transformations internally. (It may still be that it does it incorrectly on some platforms, in which case that may be a bug.) Thanks for the heads up. -- Tito ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Since this topic has lead to different sub-topic I dare ask a question (I'm a beginner both in C++ and, Oh boy, in SQLite too). Tito, do you really need the 5th argument in sqlite3_prepare_v2() i.e. oneSQL? From what I understand from your code, there's only one SQL statement to be prepared, so there would be no need for the supposedly next SQL statement. Do you reuse (reset) these statements? I was under the impression that the 5th argument is used when the SQL statement string contains more than one SQL statement. Thanks for your patience if I misunderstood something .. or all. Marian Cascaval From: Tito Ciuro tci...@mac.com To: General Discussion of SQLite Database sqlite-users@sqlite.org Sent: Mon, January 31, 2011 9:38:57 PM Subject: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases // Build the first statement sqlite3_stmt *oneStatement = NULL; const char *oneSQL = [[NSString stringWithFormat:@INSERT INTO %@(%@, %@, %@, %@) VALUES (?,?,?,?);, NSFValues, NSFKey, NSFAttribute, NSFValue, NSFDatatype]UTF8String]; int statusOne = sqlite3_prepare_v2(db, oneSQL, (int)strlen(oneSQL), oneStatement, oneSQL); ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Hello Marian, On Feb 1, 2011, at 1:28 PM, Marian Cascaval wrote: Since this topic has lead to different sub-topic I dare ask a question (I'm a beginner both in C++ and, Oh boy, in SQLite too). Tito, do you really need the 5th argument in sqlite3_prepare_v2() i.e. oneSQL? From what I understand from your code, there's only one SQL statement to be prepared, so there would be no need for the supposedly next SQL statement. Do you reuse (reset) these statements? I was under the impression that the 5th argument is used when the SQL statement string contains more than one SQL statement. Thanks for your patience if I misunderstood something .. or all. Yes, you understood right. I was using the 5th arg for debugging reasons, as I was checking whether the memory was being smashed somewhere. As for the statements, yes, I'm reusing them all the time. Regards, -- Tito ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Hello, The following code snippet runs fine on Mac OS X, but fails on the iOS simulator: // Obtain a path for the database NSString *docs = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject]; NSString *path = [[docs stringByAppendingPathComponent:@myDB.sqlite]fileSystemRepresentation]; // Open the database sqlite3 *db = NULL; int statusOpen = sqlite3_open_v2( fileSystemRepresentation, db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_AUTOPROXY | SQLITE_OPEN_FULLMUTEX, NULL); // Build the first statement sqlite3_stmt *oneStatement = NULL; const char *oneSQL = [[NSString stringWithFormat:@INSERT INTO %@(%@, %@, %@, %@) VALUES (?,?,?,?);, NSFValues, NSFKey, NSFAttribute, NSFValue, NSFDatatype]UTF8String]; int statusOne = sqlite3_prepare_v2(db, oneSQL, (int)strlen(oneSQL), oneStatement, oneSQL); // Build the second statement sqlite3_stmt *twoStatement = NULL; const char *twoSQL = [[NSString stringWithFormat:@INSERT INTO %@(%@, %@, %@, %@) VALUES (?,?,?,?);, NSFKeys, NSFKey, NSFPlist, NSFCalendarDate, NSFObjectClass]UTF8String]; int statusTwo = sqlite3_prepare_v2(db, twoSQL, (int)strlen(twoSQL), twoStatement, twoSQL); What I see is that statusTwo returns 1, and I have no idea why. What is really puzzling is that if I open the database in memory or temporary mode, it works fine in both Mac OS X and iOS! So my question I have is, why would the second sqlite3_prepare_v2 statement fail only on path-based iOS apps? :-/ Thanks in advance, -- Tito ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
On 31 Jan 2011, at 7:38pm, Tito Ciuro wrote: So my question I have is, why would the second sqlite3_prepare_v2 statement fail only on path-based iOS apps? :-/ The other question is: Is it permissable to have two statements prepared but no further, for the same database connection. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Hi Simon, On Jan 31, 2011, at 5:49 PM, Simon Slavin wrote: On 31 Jan 2011, at 7:38pm, Tito Ciuro wrote: So my question I have is, why would the second sqlite3_prepare_v2 statement fail only on path-based iOS apps? :-/ The other question is: Is it permissable to have two statements prepared but no further, for the same database connection. What do you mean by no further? In my app, I use both statements. I have trimmed down the code in this email thread to show the error. Be sure I use these two statements later on. The reason I cache the statements is to save time during inserts, since I use them a lot. If having two statements prepared is not permissible, should't it fail on Mac OS X as well? Thanks, -- Tito ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
On 31 Jan 2011, at 7:55pm, Tito Ciuro wrote: What do you mean by no further? In my app, I use both statements. I have trimmed down the code in this email thread to show the error. Be sure I use these two statements later on. The reason I cache the statements is to save time during inserts, since I use them a lot. There's probably no reason not to do that. Sorry for any alarm. If having two statements prepared is not permissible, should't it fail on Mac OS X as well? There are plenty of examples of SQLite stuff that succeeds in one compiler and fails in another, or succeeds on one OS or File System and fails in another. SQLite doesn't exhaustively error-check every operation because if would slow it down too much. So the only things that are safe to do are the things the documentation says you can do. But please ignore my previous question about having two simultaneous prepared statements. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
Hello Simon, On Jan 31, 2011, at 8:29 PM, Simon Slavin wrote: On 31 Jan 2011, at 7:55pm, Tito Ciuro wrote: What do you mean by no further? In my app, I use both statements. I have trimmed down the code in this email thread to show the error. Be sure I use these two statements later on. The reason I cache the statements is to save time during inserts, since I use them a lot. There's probably no reason not to do that. Sorry for any alarm. If having two statements prepared is not permissible, should't it fail on Mac OS X as well? There are plenty of examples of SQLite stuff that succeeds in one compiler and fails in another, or succeeds on one OS or File System and fails in another. SQLite doesn't exhaustively error-check every operation because if would slow it down too much. So the only things that are safe to do are the things the documentation says you can do. But please ignore my previous question about having two simultaneous prepared statements. Simon. No, problem, thanks for your help. After refactoring the code a bit and catching/reporting errors better, it started working again. I'm still not 100% sure why it didn't work before, which bugs me quite a bit. But, after spending some time testing it, I've had so far 100% success rate during testing and execution. Go figure... :-/ Best regards, -- Tito ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Second sqlite3_prepare_v2() call fails on iOS path-based databases
On Tue, Feb 1, 2011 at 3:38 AM, Tito Ciuro tci...@mac.com wrote: Hello, The following code snippet runs fine on Mac OS X, but fails on the iOS simulator: // Obtain a path for the database NSString *docs = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject]; NSString *path = [[docs stringByAppendingPathComponent:@ myDB.sqlite]fileSystemRepresentation]; // Open the database sqlite3 *db = NULL; int statusOpen = sqlite3_open_v2( fileSystemRepresentation, db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_AUTOPROXY | SQLITE_OPEN_FULLMUTEX, NULL); Do you need UTF8String for the sqlite3_open_v2() ? // Build the first statement sqlite3_stmt *oneStatement = NULL; const char *oneSQL = [[NSString stringWithFormat:@INSERT INTO %@(%@, %@, %@, %@) VALUES (?,?,?,?);, NSFValues, NSFKey, NSFAttribute, NSFValue, NSFDatatype]UTF8String]; int statusOne = sqlite3_prepare_v2(db, oneSQL, (int)strlen(oneSQL), oneStatement, oneSQL); // Build the second statement sqlite3_stmt *twoStatement = NULL; const char *twoSQL = [[NSString stringWithFormat:@INSERT INTO %@(%@, %@, %@, %@) VALUES (?,?,?,?);, NSFKeys, NSFKey, NSFPlist, NSFCalendarDate, NSFObjectClass]UTF8String]; int statusTwo = sqlite3_prepare_v2(db, twoSQL, (int)strlen(twoSQL), twoStatement, twoSQL); What I see is that statusTwo returns 1, and I have no idea why. What is really puzzling is that if I open the database in memory or temporary mode, it works fine in both Mac OS X and iOS! So my question I have is, why would the second sqlite3_prepare_v2 statement fail only on path-based iOS apps? :-/ Thanks in advance, -- Tito ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
