ADO RDD xHarbour

[AHF]

Lucas,

You dont have open indexes right ?

[lucasdebeltran]

No.

[AHF]

Antonio, Enrico,

How can we show or hide deleted records in ADO?

How can we enforce SET DELETED?

[Enrico Maria Giordano]

Antonio,

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

[hmpaquito]

Perhaps 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

[AHF]

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 ?

[Enrico Maria Giordano]

Antonio,

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

[AHF]

Enrico,

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 ?

[hmpaquito]

The only drawback I see is this case:

Code: Select all  Expand view  RUN

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

[Enrico Maria Giordano]

Antonio,

Enrico,

Do you mean mark a record as deleted with truly deleted in SQL using a delete field in the tables?

Yes.

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

[Rick Lipkin]

To 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

[AHF]

Rick,

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().

[thefull]

Is 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...

[Rick Lipkin]

Antonio

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

[AHF]

Rick,

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.