0

Ladies and Gents,

I'm using FMDB in an iOS application. I have some text in columns which exceeds 255 bytes. I use BASE and browse the database file, and I can query the length of the data in the columns... So I know my data is there and that it is longer than 255...

YET, when trying to pull out data from these columns, I always get a C string of exactly 255 bytes, and I have no clue whatsoever why.

Here's some piece of code (basically from - (NSString*)stringForColumnIndex:(int)columnIdx { of FMDB FMResultSet.m, and I can trap the error already there.

- (NSString*)stringForColumnIndex:(int)columnIdx {

if (sqlite3_column_type([_statement statement], columnIdx) == SQLITE_NULL || (columnIdx < 0)) {
    return nil;
}

const char *c = (const char *)sqlite3_column_text([_statement statement], columnIdx);

int xx = strlen(c); //added by me, already here it is only 255 bytes


if (!c) {
    // null row.
    return nil;
}
return [NSString stringWithUTF8String:c];
}

What am I missing? I'm using the standard supplied libsqlite3.dylib, FMDB includes sqlite.h. I tried to google similar problems to no avail for hours now.

ivanhoe1982
  • 530
  • 1
  • 4
  • 14

1 Answers1

0

This is neither a FMDB nor SQLite limitation. I use FMDB to return strings longer than 255 characters from my SQLite database all the time. I just checked:

    FMResultSet *rs = [fmdb executeQuery:@"select personnel_description from personnel where personnel_id=297"];
    [rs next];
    NSString *test2 = [rs stringForColumnIndex:0];
    NSLog(@"%s len=%d string=%@", __FUNCTION__, [test2 length], test2);
    [rs close];

and I got my 8429 character string, same length that BASE told me it was going to be.

This makes me wonder if there's something strange about your data (e.g. binary data instead of characters, DBCS, etc.). Have you tried returning as an object rather than a string and examining that? Perhaps confirm that it is a NSString and not a NSData result set, e.g.:

    id test3 = [rs objectForColumnIndex:0];
    if ([test3 isKindOfClass:[NSString class]])
        NSLog(@"It's a string");
    else
        NSLog(@"It's not");

If you really think this is a FMDB issue, you could try posting this question at the FMDB discussion. Also, I'd make sure you have the latest FMDB code, which you can retrieve from that same site.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • Sadly there doesn't seem to be anything strange about my data. FMDB returns an NSString, and as I mentioned before I trapped it already in FMDB when the c function is called, as 255. My data is pretty much plain text, I have 2000 records like that, all cut at 255 when retrieving.... Strangely it is FMDB that I use to create the database , so the insert obviously works fine.... – ivanhoe1982 Apr 30 '12 at 21:45
  • When you say it returns a NSString, do you mean that stringForColumnIndex does (which is does by definition), or that objectForColumnIndex also returns a NSString, too? Have you tried altering one of the fmdb.c sample routines to insert a string longer than 255 characters and then see what length the string it returns is? – Rob Apr 30 '12 at 21:49
  • objectForColumnIndex returns an NSCFString – ivanhoe1982 Apr 30 '12 at 21:59
  • strangely - I went into the database and changed TEXT to BLOB on the column in question - now the bastard returns a C string with full contents... i.e. it WORKS I'm not sure if it is the datatype change or some sort of a rebuilt that took place behind the scenes..... – ivanhoe1982 Apr 30 '12 at 22:04
  • That's very strange (because [the datatype of a value is associated with the value itself, not with its container](http://sqlite.org/datatype3.html)). At least you have a solution. It would be fascinating to know if you changed it back to TEXT whether you got the strange behavior again. Sorry I couldn't have been more of a help. – Rob Apr 30 '12 at 22:10
  • 1
    I kept reading about SQLite for the last 4 hours... I didn't expect it to work either... And coming back to your question: I changed it back and it still works. So I spent 4 hours basically investigating a fluke... – ivanhoe1982 Apr 30 '12 at 22:15