|
| [WD] Cascading Deletion - Manually or by Link Constraint? |
| Iniciado por guest, 29,mar. 2016 23:08 - 4 respuestas |
| |
| | | |
|
| |
| Publicado el 29,marzo 2016 - 23:08 |
How many of you use link constraints to handle the deletion of children records in your deployed applications? Does it work well? Any hiccups?
If you use SQL instead is it because you don't trust the link constraints? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,marzo 2016 - 00:08 |
Hello Curtis
I have no links at all in my analysis (over 500 files) because I don't trust anyone else to do the deletes. I have a central deletion process that handles all deletions. People tell me I am a control freak but I think that is quite normal for a programmer 
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,marzo 2016 - 01:36 |
Hi,
I have many links in my analysis. The hiccups aren't so much around the cascading deletions but more around producing the actual SQL with WX - it tries to help you. It will include tables in your SQL that you don't expect! And it was quite difficult to get rid of the unwanted tables. I say "was" because I think the situation improved with WX20, i.e. no unexpected tables. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,marzo 2016 - 06:33 |
Hi,
Depend, if you are using Database server like ms-sql , mysql , oracle, postgresql then it is save.
for flat-file database like HF classic , it is better you create delete procedure (delete from child to parent).
in DB server , in case of power OFF, when you ON back , the server will auto rollback or continue the process while for flat-file database , the data will be partial deleted . if you have delete procedure, you can just call it in the program. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,marzo 2016 - 09:34 |
Hi Curtis, I did extensive tests of cascading deletes and found it to work properly and as expected. Testing comprised simple keys only, means strings and numeric values. Not composed keys. Whether you're doing the deletions "manually" or automatically, one thing should be clear: if the index file of any of the related files is damaged then the operation will fail at some point! Same applies to propagated changes of key values, just to mention the other automatic operation in HFSQL files. It's absolutely insignificant whether you're employing manual, SQL or automatic methods!
To my sad experience, many of our customers do not repair damaged files whenever they experience an HFSQL error but rather try to get along without. In a number of cases that will work just fine (for them) and they continue their work without re-indexing / repairing their files. Even after re-indexing any number of problems can appear. What's left are flawed datafiles. I'm thinking about exporting the datafiles to CSV format, delete the datafiles and re-import the raw data. |
| |
| |
| | | |
|
| | | | |
| | |
|