SQLite: Access to internal database connection handle

Discussion of open issues, suggestions and bugs regarding UniDAC (Universal Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
MJS
Posts: 6
Joined: Wed 28 Mar 2012 16:09

SQLite: Access to internal database connection handle

Post by MJS » Wed 28 Mar 2012 19:49

Hello,

I need acces to the database connection handle, the one returned by sqlite3_open(), to register the callback function 'sqlite3_rtree_geometry_callback'. I was guessing that the variable below might be it but it always returns NULL.

p = (sqlite3 *)((TSQLiteConnection *)DM->cnApp)->SQLite;

Do you know of a way to access this handle?

Note: this is for UniDac / VCL, not dotConnect.

Regards,
Mark

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Post by AlexP » Fri 30 Mar 2012 11:09

Hello,

Below is a small sample demonstrating how to use SQLite user functions in C+Builder:

Code: Select all

Code:
// defining user function 
// where 
// InValues - Input array values of variant 
// InValues_Siz - for compatibility (is not used) 
// return - return value of variant 
Variant __fastcall Reverse(Variant *InValues, const int InValues_Size) 
{ 
// your own function body, for example 
   return ReverseString(VarToStr(InValues[0])); 
} 

void __fastcall TForm1::UniConnection1AfterConnect(TObject *Sender) 
{ 
// Registering user function 
// where: 
// UniConnection1 - pointer to TUniConnection 
// "REVERSE" - name of user function 
// 1 - number of user function parameters 
// Reverse - pointer to user function 

   TLiteUtils::RegisterFunction(UniConnection1,"REVERSE",1,Reverse); 
} 

// Using user function 
void __fastcall TForm1::Button1Click(TObject *Sender) 
{ 
   UniQuery1->SQL->Text = "select REVERSE('ABCD')"; 
   UniQuery1->Open(); //result 'DCBA' 

}

MJS
Posts: 6
Joined: Wed 28 Mar 2012 16:09

Post by MJS » Fri 30 Mar 2012 19:01

Hi Alex,

Thanks for that sample, the TLiteUtils RegisterFunction call may not work in this case though.

I'm using an exported SQLite function called 'sqlite3_rtree_geometry_callback' that is not exposed by UniDac (although it probably could be). This exported function allows you to register your own call back function that is only called on spatial queries involving the rtree index. I'm guessing the TLiteUtils RegisterFunction will only work as a non-spatial callback.

In my case I've successfully accessed 'sqlite3_rtree_geometry_callback' like so:

__sqlite3_rtree_geometry_callback = (_sqlite3_rtree_geometry_callback)GetProcAddress(SQ3,"sqlite3_rtree_geometry_callback");

but can't register my own callback using sqlite3_rtree_geometry_callback here:

__sqlite3_rtree_geometry_callback(SQLite, "circle", circle_geom, 0);

because I don't have a valid SQLite database handle as the first parameter (always is NULL).


Regards,
Mark

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Post by AlexP » Mon 02 Apr 2012 13:38

Hello,

In UniDAC, there is no support for the ability to get the cursor to a loaded SQLite library for calling the methods exported by it. If you have the UniDAC version with source code, you can add the needed functionality by yourself.

P.S. We will review the possibility of including such method in UniDAC in one of the next versions.

MJS
Posts: 6
Joined: Wed 28 Mar 2012 16:09

Post by MJS » Mon 02 Apr 2012 16:02

>>In UniDAC, there is no support for the ability
>>to get the cursor to a loaded SQLite library for
>>calling the methods exported by it.

I have in fact done this and the 'sqlite3_rtree_geometry_callback' functionality works well.


>>P.S. We will review the possibility of including
>>such method in UniDAC in one of the next versions.

It appears you are already setting the TSQLiteConnection::SQLite variable to the internal database handle, not sure why it's not 'sticking' at runtime though.

Regards,
Mark

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Post by AlexP » Thu 05 Apr 2012 10:16

Hello,

TSQLiteConnection::SQLite is necessary at the inside level for realization of user functions, therefore we didn't take it out to the outside level. In one of the next versions, we will either implement the SQLite R*Tree support or provide possibility of retrieving TSQLiteConnection::SQLite

MJS
Posts: 6
Joined: Wed 28 Mar 2012 16:09

Post by MJS » Tue 10 Apr 2012 02:34

>>In one of the next versions, we will either implement...

Cool, thanks Alex. Implementing SQLite R*Tree support would be ideal.


Regards,
Mark

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Post by AlexP » Tue 10 Apr 2012 08:42

Hello,

Currently we are working at the SQLite support implementation as a separate product, perhaps, R*Tree support will be included into this version or the next one.

Post Reply