SQLWIN - a free RDD for SQL

[thefull]

Hi Antonio!

This RDD is designed only for FiveWin? You want to run this RDD on Linux too?

Sorry for my bad english!

Mucho me temo que si usan ADO para los diferentes motores, esto solamente funcionará en Windows.

El mayor problema de usar una implementación como el RDD, es que si no se usa ADO, vas a tener que linkar todas las librerias de todos los motores que soporte el RDD, esto es otra pega.

No estoy muy puesto, pero se supone que la funcion DbCreate() por ejemplo, permitirá tipos nativos , no ?
No es lo mismo un tinyint, smallint, mediunint o int, todos son para harbour del NUMERIC, pero a la hora de crearse ,
¿Se va a tener en cuenta la longitud del campo para determinar que tipo nativo, según claro esta el motor SQL a usar, le corresponde ?

[Antonio Linares]

Vailton,

This RDD does not need FiveWin, so we can adapt it to Linux too

You are welcome to join its development

[Antonio Linares]

Rafa,

This RDD does not use ADO at all. It just still has old code from ADORDD that has to be deleted.

The SQLWIN RDD just issues SQL sentences: It translates Db...() functions to SQL code, so we can use it with any database engine that supports SQL.

[vailtom]

You are welcome to join its development

Antonio, many thanks! What the next step?

[Antonio Linares]

Vailton,

Please download it from here:

www.fivetechsoft.com/files/sqlwin.zip

Build it with Harbour or xHarbour and test it. Then review its source code to understand how it works. It looks complex but in fact its real easy

[Antonio Linares]

A new version that implements FieldPut() (fields values assignments):

www.fivetechsoft.com/files/sqlwin.zip

[Antonio Linares]

New version that implements DbAppend():

www.fivetechsoft.com/files/sqlwin.zip

[vailtom]

Before continuing, let me understand and ask some questions about this tool:

* Standard C functions are faster and have a direct access to the API of many database engines, such as MySQL, PostgreSQL & Firebird ... how we can use this within this RDD?

We could offer access to many native database engine and get a better yield with C source code?

* We need to implement a temporary buffer for editing data and send it to the server when a COMMIT or RDD_GOCOLD () is sent - for any server API.

* Some queries are specific to each server. We treat this in any way that filtering according to the SQL engine used. Again to get a better result I believe we should use some routines written in C.

I have some comments on the RDD for MySQL and PostgreSQL initially, after his comments.

[Antonio Linares]

Vailton,

At this stage we are just translating the Db...() functions into their equivalents SQL sentences.

Next step is to make a real connection and it will be done using language C (C wrappers), to turn it real fast. Some connections may require ODBC, others will use the native DLLs for each database engine.

Of course, we can optimize the SQL for different database engines, it is just a matter of using do case ... endcase in the source code, and build the appropiate sentences for each database engine.

[Antonio Linares]

Vailton,

>
* We need to implement a temporary buffer for editing data and send it to the server when a COMMIT or RDD_GOCOLD () is sent - for any server API.
>

The buffer is going to be initialized and stored in:

Code: Select all  Expand view  RUN

   local aWAData := Array( WA_SIZE )


and later on, accessed as:

Code: Select all  Expand view  RUN

   local aWAData := USRRDD_AREADATA( nWA )


[vailtom]

Hi Antônio!
Excuse me for so many questions, it would just understand that their goals.

At this stage we are just translating the Db...() functions into their equivalents SQL sentences.

Okay, I understand this. Another issue is: the result set will be maintained in its original format and converted via C (as DBFCDX / NTX, etc.) or you will be when the data are obtained, to convert them and place them within this ARRAY?

I ask this, because the GETVALUE / PUTVALUE routines would have to work with this logic - am I correct?

Thank you for your attention.

[Rick Lipkin]

Antonio

Not that it is a big deal .. and I know ADO does not seem to want to use the native MS SQL and Oracle indexes .. how do you plan to get around that . . I was thinking the index's for the SQL tables were governed by the database engine ??

Rick Lipkin

[Antonio Linares]

Rick,

>
how do you plan to get around that . . I was thinking the index's for the SQL tables were governed by the database engine ??
>

Its easy The idea is to store the indexes tags and expresions in the server, so when we issue some SQL sentences that require indexes then we use:

... ORDER BY <index_expression_stored_in_server>, sql_recno

i.e.:

SELECT ALL FROM `test_dbf` ORDER BY `Name`, `sql_recno` WHERE `sql_deleted`!= 'T'

we have to previously retrieve those indexes expressions from the server when we open the tablename (DBF) with the RDD

[Antonio Linares]

Vailton,

We can keep the current record values in the workarea data array ( local aWAData := USRRDD_AREADATA( nWA ) ).

We can decide how many records we can to keep in the array, or just use the current record values.

Or we could use a local DBF to store a recordset result (some records).

The beauty of this RDD is that being open source we can modify it as we want to

[Antonio Linares]

Rick,

All we need is to create and keep an extra table named SQL_TABLES (or similar) and there we store the name of each tablename that we are going to use, with its indexes tags and expressions, and any other extra info that we may need.

When we create a new INDEX, all its info (tag, expression) is stored inside SQL_TABLES in the server.

This way we can have in the server all the required info to be used from each local application. When the local EXE is going to use a SQL table, we locate it in SQL_TABLES and retrieve all the info that the RDD needs to manage it.

Its quite simple