Page 2 of 3
Re: RDD SQL!
Posted: Thu Apr 02, 2009 1:13 pm
by sudip
Hello,
Grigory sent me the solution:-
Hi Sudip,
RDDI_AFFECTEDROWS returns the number off affected rows AFAIK.
> How can I save records into database using HbSqlDD.
You should use the command INSERT INTO <table> .. for append record and UPDATE
<table> SET .. for replace record(s).
Thank you Grigory!!!
You will be kind enough if you please send one sample regarding this.
With best regards.
Sudip
Re: RDD SQL!
Posted: Thu Apr 02, 2009 1:35 pm
by Roberto Lopez
sudip wrote:Hello,
Grigory sent me the solution:-
Hi Sudip,
RDDI_AFFECTEDROWS returns the number off affected rows AFAIK.
> How can I save records into database using HbSqlDD.
You should use the command INSERT INTO <table> .. for append record and UPDATE
<table> SET .. for replace record(s).
Thank you Grigory!!!
You will be kind enough if you please send one sample regarding this.
With best regards.
Sudip
The rdd author explain this explicity in the text I've posted:
Code: Select all
The programmer must call SQL command explicitly to modify SQL tables.
So, it must be done the same way that table is created and records added in the procedure 'createtable()' in the uploaded sample, using PURE SQL via RDDINFO(RDDI_EXECUTE,... ) function.
I've was talking about a different thing.
When you modify a table via
xBase code and only the recordset is changed, if we could know what records were affected by these commands we could create some kind of SQL COMMIT command to 'flush' the changes to
true backend table.
Regards,
Roberto.
Re: RDD SQL!
Posted: Thu Apr 02, 2009 3:50 pm
by sudip
Hello Roberto,
Roberto wrote:
When you modify a table via xBase code and only the recordset is changed, if we could know what records were affected by these commands we could create some kind of SQL COMMIT command to 'flush' the changes to true backend table.
Is there any way to know which temporary records are effected? And then we have to create generic sql string to commit.
Some how the reason (from my very basic knowledge) I think TMySqlServer will be more flexible and efficient. This is not my strong view, because I know very little about database programming.
With best regards to you all.
Sudip
Re: RDD SQL!
Posted: Thu Apr 02, 2009 4:02 pm
by Roberto Lopez
sudip wrote:Hello Roberto,
I know very little about DBMS Server programming. But from this very basic knowledge, some questions came to my mind. I want to get a clear picture before working on any library (because database programming is my bread and butter
)
<...>
[Sudip
I can't answer all your questions about efficiency of different methods, because (IMHO) it will require extensive tests and benchmarking to be sure about that (maybe someone that had done it can help us on this).
In general (using a remote server or not) I prefer to copy the data to arrays, work with them and finally open the tables make the updates and close it as quick as possible.
Maybe that is not the faster way, but I privilege the reliability over the speed.
Please, consider that this is my personal opinion only, perhaps this is not the better solution for you.
Regards,
Roberto.
Re: RDD SQL!
Posted: Thu Apr 02, 2009 4:15 pm
by sudip
Roberto Lopez wrote:
I can't answer all your questions about efficiency of different methods, because (IMHO) it will require extensive tests and benchmarking to be sure about that (maybe someone that had done it can help us on this).
In general (using a remote server or not) I prefer to copy the data to arrays, work with them and finally open the tables make the updates and close it as quick as possible.
Maybe that is not the faster way, but I privilege the reliability over the speed.
Please, consider that this is my personal opinion only, perhaps this is not the better solution for you.
Regards,
Roberto.
Sorry, after writing my previous message, I thought I shouldn't write those strong words. And I edited my previous message. In the mean time you replied my message.
But, your reply gave me some insight about database programming.
Yes, I shall wait.
With best regards.
Sudip
Re: RDD SQL!
Posted: Thu Apr 02, 2009 5:37 pm
by Rathinagiri
In general (using a remote server or not) I prefer to copy the data to arrays, work with them and finally open the tables make the updates and close it as quick as possible.
Thanks Roberto. Nice words.
Re: RDD SQL!
Posted: Thu Apr 02, 2009 7:13 pm
by Roberto Lopez
Roberto Lopez wrote:
I've wrote a private message to the rdd author (Mindaugas Kavaliauskas) asking about that.
I'll post here any info regarding that.
Mindaugas Kavaliauskas, had responded to my message about SQLRDD.
The mechanism to know which records were changed is not implemented yet, but he has plans to do it.
When that be implemented, could be easy to create a generic function (ie: SqlCommit()) to update the tabke on the server.
Regards,
Roberto.
Re: RDD SQL!
Posted: Fri Apr 03, 2009 4:00 am
by sudip
Roberto Lopez wrote:
Mindaugas Kavaliauskas, had responded to my message about SQLRDD.
The mechanism to know which records were changed is not implemented yet, but he has plans to do it.
When that be implemented, could be easy to create a generic function (ie: SqlCommit()) to update the tabke on the server.
Thanks a lot
With best regards.
Sudip
Re: RDD SQL!
Posted: Fri Apr 03, 2009 1:08 pm
by Roberto Lopez
sudip wrote:
Thanks a lot
With best regards.
Sudip
And... since you are testing... you could give a try to ADORDD, even I have 'personal problems' with it
I mean, that to use it, you must install an additional piece of software (MySql ODBC Connector 3.51 from mysql.com) and I don't like to work so, specially if there is a MS technology 'mediating' between your application and your data.
But, maybe that in a 'controlled situation' (ie: if you have quick access to machines involved to control it) could be useful for you.
Regards,
Roberto.
Re: RDD SQL!
Posted: Fri Apr 03, 2009 2:08 pm
by sudip
Roberto Lopez wrote:
And... since you are testing... you could give a try to ADORDD, even I have 'personal problems' with it
I mean, that to use it, you must install an additional piece of software (MySql ODBC Connector 3.51 from mysql.com) and I don't like to work so, specially if there is a MS technology 'mediating' between your application and your data.
But, maybe that in a 'controlled situation' (ie: if you have quick access to machines involved to control it) could be useful for you.
I tried ADORDD a few months ago. But, faced problem, e.g., checking existence of table in a database!!! I received solutions. But solutions have more MS Codes!!! Now, I am also facing some problems with my Dbf to Ms Excel utility. And some times quick access (like ADO) may not be reliable access
I want a reliable, mature and stable system. Because this is my bread and butter!!!
So, shall I continue my MySql journey with TMySqlServer library? What is your advice?
With best regards.
Sudip