Page 1 of 1

revDatabaseColumnTypes - data type definitions?

Posted: Tue Apr 19, 2011 10:58 pm
by Steve Denney
Hi, revDatabaseColumnTypes returns the following data types:
BIT, CHAR, STRING, WSTRING, BLOB, TIMESTAMP, DATE, TIME, DATETIME, FLOAT, DOUBLE, INTEGER, SMALLINT, WORD, BOOLEAN, LONG
but i can't find any run-rev definition of what these actually mean (or how they relate to other database data types esp. SQL and MS Access).
Like, I can take my best guess--but it'd be nice to have the actual definition.
Surely the definitions muct be somewhere, I just can't find them :(
Steve

Re: revDatabaseColumnTypes - data type definitions?

Posted: Wed Apr 20, 2011 9:14 am
by Mark
Steve,

Those datatypes are returned by your database system and have nothing to do with RunRev. Refer to the documentation of your database.

Best,

Mark

Re: revDatabaseColumnTypes - data type definitions?

Posted: Wed Apr 20, 2011 9:25 pm
by Steve Denney
Sorry Mark, I wish that were so, but it's not the case. I pasted those data types from the LC dictionary.
If it were I'd receive different results for differing databases i.e. MS access could return autonumber instead of integer. SQL might say varchar instead of string.
I think the run rev data types relate to some flavour of C but I've done quite a bit of searching and can't find them anywhere that's not linked to rev (and never with definitions).
Steve

Re: revDatabaseColumnTypes - data type definitions?

Posted: Wed Apr 20, 2011 10:30 pm
by shaosean
One nice thing about Rev is the lack of typecasting of variables so, other than the database BLOB* type, you can cram any database column type in to a Rev variable and inversely you can put any Rev variable in to a database column (so long as it will match the column type).. If you want to know exactly what they can hold, you will need to follow Mark's advice and look in the database vendor's documentation..

*BLOBs are binary data so you need to take care when writing your SQL statements in Rev that you use the binary prefix (*b) on the variable name when sending to the database..

ps.. You might have better luck posting the database forum..

Re: revDatabaseColumnTypes - data type definitions?

Posted: Wed Apr 20, 2011 11:56 pm
by Mark
Hi Steve,

Yup, it is a bit of a surprise for me, but I did a quick test and you're right. Apparently, where MySQL returns "VARCHAR", LiveCode shows "STRING". This can be quite confusing when you try to set up your database properly. I didn't remember this, because I always use PHP as a layer between LiveCode and MySQL. PHP is a wonderful language to talk to a MySQL database.

Shaosean is right about not having to know the variable types while working with variables in LiveCode. Unfortunately, you still need to know these variable types if you have to set up the database yourself. You need to know, for example, that a unicode variable is not a BLOB but instead a VARCHAR with UTF8 text encoding, even though UTF8 is binary data. You also need to know that you need to convert your LiveCode unicode data from UTF16 to UTF8 when you try to save it to a database field with UTF8 text encoding. Therefore, I think that knowledge of database types may be useful.

I still think that reading about data types in the MySQL documentation will be useful for you.

Kind regards,

Mark

Re: revDatabaseColumnTypes - data type definitions?

Posted: Thu Apr 21, 2011 6:56 am
by Steve Denney
Oops, didn't realise there was a database forum.
Found it now and I will post the Q there :)
The only runRev definition mentioned (dictionary & anywhere I could find) refers to the Blob data type. The others are make your own best guess. They are fairly self explanatory to anyone who's had dealings with databases, but I'd rather have an official definition to pass on to the person who's going to be setting up the installations.
I intend to put in checks & traps to ensure user-updates fit the database's requirements. And the installer will set up the app accordingly (thankfully we've moved on from expecting the app to set itself up automatically).
Thanks shaosean and Mark for your help.
Steve