Re: ADO RDD xHarbour
Posted: Thu Apr 09, 2015 7:28 pmLucas,
You dont have open indexes right ?
You dont have open indexes right ?
FiveTech Software tech support forums
www.FiveTechSoft.com
https://fivetechsupport.com/forums/
ADO RDD xHarbour
https://fivetechsupport.com/forums/viewtopic.php?f=3&t=30266
Page 26 of 70
Posted: Thu Apr 09, 2015 7:28 pmRe: ADO RDD xHarbour
Posted: Thu Apr 09, 2015 7:55 pmNo.
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 9:23 amAntonio, Enrico,
How can we show or hide deleted records in ADO?
How can we enforce SET DELETED?
How can we show or hide deleted records in ADO?
How can we enforce SET DELETED?
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 9:41 amAntonio,
As far as I know, there is no direct support for deleted records in SQL. You have to add a logical field and use it in WHERE clauses, I'm afraid.
EMG
AHF wrote:Antonio, Enrico,
How can we show or hide deleted records in ADO?
How can we enforce SET DELETED?
As far as I know, there is no direct support for deleted records in SQL. You have to add a logical field and use it in WHERE clauses, I'm afraid.
EMG
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 9:51 amPerhaps a first version of ADORDD no need to treat the deleted records because generally all have SET DELETED ON at the beginning of our programs
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 10:19 amEnrico,
In fact this is not a problem because deleting records in SQL will wipe records off the table and we cannot recover them again. Is this true for all DB Sql ?
In fact this is not a problem because deleting records in SQL will wipe records off the table and we cannot recover them again. Is this true for all DB Sql ?
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 10:41 amAntonio,
I don't know but we have to make it "database aware", haven't we?
EMG
AHF wrote:Enrico,
In fact this is not a problem because deleting records in SQL will wipe records off the table and we cannot recover them again. Is this true for all DB Sql ?
I don't know but we have to make it "database aware", haven't we?
EMG
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 11:13 amEnrico,
Do you mean mark a record as deleted with truly deleted in SQL using a delete field in the tables?
In dbf apps we have to pack to clean it and some kind of recycle to recover it when adding records.
If we truly delete it nothing else mus be done. Although recall and pack exists in adordd but do nothing.
The trials we ae running with our app there is no problem but maybe others have a different approach.
Is it worth to do it ?
What do you think ?
Do you mean mark a record as deleted with truly deleted in SQL using a delete field in the tables?
In dbf apps we have to pack to clean it and some kind of recycle to recover it when adding records.
If we truly delete it nothing else mus be done. Although recall and pack exists in adordd but do nothing.
The trials we ae running with our app there is no problem but maybe others have a different approach.
Is it worth to do it ?
What do you think ?
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 11:30 amThe only drawback I see is this case:
My opinion: will be few occasions or applications that this circumstance. At the moment I do not think it worthwhile to consider it. Perhaps ADORDD v2.00
- Code: Select all Expand view
- nRec: = RecNo()
DELETE
GO nRec // Ok dbf. ADO Fail
My opinion: will be few occasions or applications that this circumstance. At the moment I do not think it worthwhile to consider it. Perhaps ADORDD v2.00
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 11:51 amAntonio,
Yes.
No, it's not worthwhile.
EMG
AHF wrote:Enrico,
Do you mean mark a record as deleted with truly deleted in SQL using a delete field in the tables?
Yes.
AHF wrote:In dbf apps we have to pack to clean it and some kind of recycle to recover it when adding records.
If we truly delete it nothing else mus be done. Although recall and pack exists in adordd but do nothing.
The trials we ae running with our app there is no problem but maybe others have a different approach.
Is it worth to do it ?
What do you think ?
No, it's not worthwhile.
EMG
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 12:42 pmTo All
I think each RDMS handles deleted records a bit differently .. As in all Sql Databases, when a record is Deleted, it just drops off the 'radar' and there is no need to even worry about it or even to 'Recall' it .. I do not even think you can get it back unless you use some sort of 'roll back' technique.
I will say this .. it is obvious with Ms Access, that the size of the database DOES NOT decrease when you have deleted records so they still must be there, but are just not accessible, hence why you have to Compact and Repair the database from time to time. And, my guess when DBA's tune their MS Sql and Oracles of the world, deleted records are purged during that process.
In any case .. in my experience as a developer with Sql databases .. once a record is deleted, you might as well forget about it and 'Setting Deleted (On or Off )' is irrelevant.
Rick Lipkin
I think each RDMS handles deleted records a bit differently .. As in all Sql Databases, when a record is Deleted, it just drops off the 'radar' and there is no need to even worry about it or even to 'Recall' it .. I do not even think you can get it back unless you use some sort of 'roll back' technique.
I will say this .. it is obvious with Ms Access, that the size of the database DOES NOT decrease when you have deleted records so they still must be there, but are just not accessible, hence why you have to Compact and Repair the database from time to time. And, my guess when DBA's tune their MS Sql and Oracles of the world, deleted records are purged during that process.
In any case .. in my experience as a developer with Sql databases .. once a record is deleted, you might as well forget about it and 'Setting Deleted (On or Off )' is irrelevant.
Rick Lipkin
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 2:14 pmRick,
Thanks for the info.
Inside transactions if it fails everything rolled back, but its the only situation I can find where his happens.
Are you trying adordd. All feed back its a great help.
Im trying it for a big app conversion and browses with relations run without any code change except a autoinc field to use for recno().
Thanks for the info.
Inside transactions if it fails everything rolled back, but its the only situation I can find where his happens.
Are you trying adordd. All feed back its a great help.
Im trying it for a big app conversion and browses with relations run without any code change except a autoinc field to use for recno().
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 3:02 pmIs possible get library for Borland C 5.5 ?
Today, direct from Harbour, is imposible make this library.
Regards
O te pago una cerveza si lo consigues...
Today, direct from Harbour, is imposible make this library.
Regards
O te pago una cerveza si lo consigues...
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 4:01 pmAntonio
I use the ADO Class and methods to create recordsets to manage SQL.. and creating separate recordsets based on the primary key and the foreign key or a single recordset based on inner and outer joins.. not necessarily like we used to with .Dbf.
I am watching this thread with interest.
Rick Lipkin
I use the ADO Class and methods to create recordsets to manage SQL.. and creating separate recordsets based on the primary key and the foreign key or a single recordset based on inner and outer joins.. not necessarily like we used to with .Dbf.
I am watching this thread with interest.
Rick Lipkin
Re: ADO RDD xHarbour
Posted: Fri Apr 10, 2015 5:18 pmRick,
Thats the SQL normal way.
Unfortunately we would get only one recordset (joined) and to simulate Dbf behavior and working with already written apps that's not possible because it breaks completely the code.
Thus I'm working with true relations issuing SELECTS for each child only if key changes.
The speed suffers but its completely acceptable.
I'm converting a big app and till now in browses didn't need to change a single line of code!
We have indexes, scopes, seeks, relations, filters (translated to Selets) using exactly the same app source code.
Take a look at the adordd.
Your comments and ideas would be most welcome.
Ill post new version with lot of bugs corrected tomorrow morning.
The actual posted version has been much modified and is very outdated.
Thats the SQL normal way.
Unfortunately we would get only one recordset (joined) and to simulate Dbf behavior and working with already written apps that's not possible because it breaks completely the code.
Thus I'm working with true relations issuing SELECTS for each child only if key changes.
The speed suffers but its completely acceptable.
I'm converting a big app and till now in browses didn't need to change a single line of code!
We have indexes, scopes, seeks, relations, filters (translated to Selets) using exactly the same app source code.
Take a look at the adordd.
Your comments and ideas would be most welcome.
Ill post new version with lot of bugs corrected tomorrow morning.
The actual posted version has been much modified and is very outdated.