Guidance Forums / Rapid-Q Basic / DLL return value compatibility

Search 搜索
Home Home

Forum List • Thread List • Reply • Refresh • New Topic • Search • Previous • Next First 1 Last
Message1. DLL return value compatibility
Posted by: 2005-01-13 00:21:11
I am trying to map the SQLITE3.DLL. But I am not sure how to map functions that use double, int64 or utf16 string encoding.

Is the C double type, the same as Rapid-Q's DOUBLE?

Does Rapid-Q have a 64-bit integer type? It appears LONG is only 32 bits, and that is the longest integer I saw. The C API declares it as "long long int". Any ideas how I can use this return value?  (sqlite3_last_insert_rowid returns this 8 byte monster, and as that can be a very important function, I want to try to be able to use it.)

Can Rapid-Q handle utf16 text?  I don't recall ever seeing that it does, but if someone can tell me otherwise, and point me to details on it, I will try to map those functions as well.

Message2. Re: DLL return value compatibility
Posted by: JohnK 2005-01-13 05:05:01
You are entering a grey zone with rapidQ here. HotBasic is your better option here. But if that is not possible and you need RQ, then you can "handle" these numbers by only if variables are passed from the DLL by reference (i.e., BYREF MyNum AS LONG). Get the pointer then use CPYMEM to move the bits over to a string pointer *yes string* of correct dimensions. Then you have to always be doing the math yourself! (Offset+base)

In windows a long_Long_int is a structure--in RQ it is something like this

 lowword AS DWORD
 highword AS DWORD
C double type, the same as Rapid-Q's DOUBLE?
probably, find out the #bytes used by C DOUBLE, I am pretty sure a float is the same as SINGLE
Does Rapid-Q have a 64-bit integer type?
No, you would have to put together your own math calculations with Doubles and work with the rounding errors.

This isn't fun stuff, but is probably possible with work.
I'm basic too
Message3. Re: DLL return value compatibility
Posted by: 2005-01-13 07:05:15
Looks like the C double and the RQ double are the same number of bytes (8 each), so hopefully I can just transfer them.

the functions are returning the 64bit integers by value.
I am thinking a workaround is to declare the function as double (since that is 8 bytes), then memcopy the 8 bytes into the low four bytes into a 4 byte integer. (And if someone is trying to create a 200 billion plus record database, they ain't gonna be coding it in rapid-q. so I think it is safe to dump the high bytes.


 FUNCTION my_function .... AS LONG

  d = DLL_function()
  memcpy VARPTR(l),VARPTR(d),4
  result = l

Do you think this will work?

Message4. Re: DLL return value compatibility
Posted by: OvalX 2005-01-13 23:06:39
I'd like to work with SQLite3.dll too, but I don't know how to use declarations of commands like sqlite3_open and sqlite3_exec (or other basic database commands). I welcome simply code example... Thanx. Slavo
Message5. Re: DLL return value compatibility
Posted by: 2005-01-13 23:24:54
   I'm still working on it, but for open, this should work:

declare function sqlite3_open LIB "SQLITE3.DLL" ALIAS "sqlite3_open" (byref filename as string, byref db as long) as long

declare function sqlite3_close LIB "SQLITE3.DLL" ALIAS "sqlite3_close" (db as long) as long

dim db as long

if sqlite3_open("test.db",db)=SQLITE_OK then
  ' database opened successfully.
end if

For the exec, I only use it to do action queries, and as such has not played with using the callback.

declare sqlite3_exec LIB "SQLITE3.DLL" ALIAS "sqlite3_exec" (db as long, byref sql as string, pCallback as long, pUserData as long, byref pErrMsg as long) as long

'run a query
if sqlite3_exec(db,"DELETE * FROM T1;", 0,0,0)=SQLITE_OK then
  'query ran okay
end if

By the end of this week, I hope to have tested how to use the pCallback, pUserData and pErrMsg arguments. For action queries, they can simply be set to 0.

Message6. Re: DLL return value compatibility
Posted by: 2005-01-14 02:14:07
Errors in my last post

For sqlite3_open, you must put the filename in a string variable and pass that to the function

dim filename as string
filename = "test.db"
sqlite3_open(filename, db)

With sqlite3_exec, the declaration should be:

declare function sqlite3_exec LIB "SQLITE3.DLL" ALIAS "sqlite3_exec" (db as long, byref sql as string, pCallback as long, pUserData as long, ppErrMsg as long) as long

for the ppErrMsg, use must specify either

dim pErrmsg as long
dim sql as string

sql = "Delete * from T1;"
sqlite3_exec(db, sql, 0, 0, varptr(pErrMsg) )
then if it returns an error you must declare and call


sqlite3_exec(db, sql, 0, 0, 0 )
then if there is an error, get the error message from sqlite3_errmsg(db)

Message7. Re: DLL return value compatibility
Posted by: OvalX 2005-02-22 15:07:22
2005-Feb-19 - SQLite version 3.1.3 Released!!!
Version 3.1.3 cleans up some minor issues discovered in version 3.1.2.

Thanx for hint, David! Slavo
This example code works for me:

 CONST sqlite3_ok = 0	'*/ successful result */

 DECLARE FUNCTION sqlite3_open LIB "SQLITE3.DLL" ALIAS "sqlite3_open" (byref filename AS STRING, byref db AS LONG) AS LONG
 DECLARE FUNCTION sqlite3_close LIB "SQLITE3.DLL" ALIAS "sqlite3_close" (db AS LONG) AS LONG
 DECLARE FUNCTION sqlite3_exec LIB "SQLITE3.DLL" ALIAS "sqlite3_exec" (db AS LONG, byref sql AS STRING, pCallback AS LONG, pUserData AS LONG, ppErrMsg AS LONG) AS LONG
 DECLARE FUNCTION sqlite3_get_table  LIB "SQLITE3.DLL" ALIAS "sqlite3_get_table" (db AS LONG, sql AS STRING, lpTable AS LONG, nRow AS LONG, nColumn AS LONG, lpErrMsg AS LONG) AS LONG
 DECLARE FUNCTION sqlite_free_table LIB "SQLITE3.DLL" ALIAS "sqlite3_free_table" (lpTable AS LONG) AS LONG

 DIM filename AS STRING
 filename = "data.db"

 IF FILEEXISTS(CURDIR$ + "\" + filename) THEN KILL CURDIR$ + "\" + filename
 IF sqlite3_open (filename, db) = sqlite3_ok THEN	' database opened successfully.
  PRINT "database opened successfully on " + TIME$

  DIM sql      AS STRING
  DIM nrows    AS LONG
  DIM ncolumns AS LONG
  DIM perrmsg  AS LONG
  DIM lptable  AS LONG
  DIM result   AS LONG
  DIM lerrmsg  AS LONG
  DIM ipos     AS INTEGER
  DIM bcar     AS BYTE
  DIM litems   AS LONG
  DIM prow     AS LONG
  DIM pcol     AS LONG
  DIM sversion AS STRING
  DIM icounter AS LONG
  DIM nfila    AS LONG
  DIM i        AS BYTE

  sql = "create table table1(" + _
   "strings varchar(10)," + _
   "numbers int" + _
  sqlite3_exec (db, sql, 0, 0, 0)

  sql = "begin;"
  sqlite3_exec (db, sql, 0, 0, 0)
  FOR i = 1 TO 20
   sql = "insert into table1 values('text" + STR$(i) + "', '" + STR$(21 - i) + "');"
   sqlite3_exec (db, sql, 0, 0, 0)
  NEXT i
  sql = "commit;"
  sqlite3_exec (db, sql, 0, 0, 0)

  sql = "select * from table1"
  result = sqlite3_get_table (db, sql, VARPTR(lptable), VARPTR(nrows), VARPTR(ncolumns), VARPTR(perrmsg))
  IF result = sqlite3_ok THEN
   nfila = -1
   PRINT "--- dump database ---"
   FOR litems = 0 TO (nrows * ncolumns) + 1          ' with field names
    pcol = (litems MOD ncolumns)
    IF pcol = 0 THEN
     nfila = nfila + 1
     sversion = STR$(nfila) + CHR$(9)
    END IF
    memcpy VARPTR(prow), lptable + (4 * litems), 4
    icounter = 0
     memcpy VARPTR(bcar), prow + icounter, 1
     IF (bcar = 0) THEN EXIT DO
     sversion = sversion + CHR$(bcar)
    IF pcol = 0 THEN
     sversion = sversion + CHR$(9)
     ELSE: PRINT sversion
    END IF
   sqlite_free_table VARPTR(lptable)
   PRINT "------ end dump -----"
   PRINT "error in sqlite_get_table: ", lerrmsg
  PRINT "database closed on " + TIME$
  SHOWMESSAGE "number of rows: " + STR$(nrows) + CHR$(13) + _
   "number of columns: " + STR$(ncolumns) + CHR$(13)

Forum List • Thread List • Reply • Refresh • New Topic • Search • Previous • Next First 1 Last
© Sat 2024-6-22  Guidance Laboratory Inc. Hits:0