Dependent tables have absolute references!?

[jartman]

I just noticed a problem which has me rather concerned. We use a second instance of our application for test and development. I recently wrote some code to automatically dump all of the table structure info for both instances and compare them, and found that it reports differences for many (not all) of the referential integrity links. When I looked at the table structure files, it shows dependent tables as being referenced by their absolute path names instead of by aliases.

This is not critical for my immediate purpose, but what if I install multiple instances of the app which use different data sets? Then the instances would be cross-linked into each other's data, and a royal mess will ensue. I don't know why this didn't happen when we created the test instance, because we just copied the real app's data into a new directory en masse.

There doesn't appear to be any way to select the location of the tables by alias when you're editing the table structure. Actually, it seems you can only select tables which are in the same directory as the table you're adding RI to, which is fine with me. Maybe the problem is confined to the enumRefIntStruct method, i.e. maybe it's tacking on the absolute path. Can anyone shed any light on what's happening here?

- John

 

[TonyMcGuire]

As with Lookup Tables, Referential Integrity does indeed use Absolute Paths. Even though you can select tables by alias, Paradox converts any choice of alias to the absolute path for both of these.

There is no way around; or if there is no one has ever made the workaround public knowledge.

Tony McGuire

http://forums.tonymcguire.com

 

[jartman]

But I know I didn't go in and manually recreate all the tables when I moved the test application. That would have taken a week so I'd definitely remember! How did they wind up pointing to the new directory? Maybe a better question is: how do you handle this problem when you deploy an app? My method has been to copy the tables from my test app and then empty them (I don't have to deploy new instances very often).

Also, you say that you can select the table by alias - I see it in the table lookup tab, but not in the referential integrity tab of the restructure dialog.

- John

 

[TonyMcGuire]

What version of Paradox are you using?

As to 'how do you handle this problem...?'

Everyone I have contact with recommend AGAINST using the builtin RI. Roll your own, and you won't have nearly the same limitations; nor problems.

Change of directory - no idea. Maybe you restructured, and Paradox reset based on :work:. I really have no idea.

Tony McGuire

http://forums.tonymcguire.com

 

[jartman]

I'm using version 9.

Just to satisfy my curiosity, I'll try copying the data set again and watch closely to what happens. I'll check the RI links in the VAL files before and after running the app.

But your other comment is a real eye-opener. I always trusted the RI implicitly because I thought it was part of the database engine, not part of Paradox. Is that incorrect?

It would be a major undertaking to re-do the RI links now, I'd have to scour about 150 forms for references to the relevant fields. Yikes. But I'll definitely take your advice for new tables and future apps.

If you don't mind the conversation taking a bit of a turn, this brings up another question I've had for years and have not been able to resolve. If I were to try to roll my own RI, I would need a reliable way to capture an edit on a field.

Call me crazy, but I've never found a way to do it, at least that I trust enough to depend on. It's possible for a value to post to a table without triggering action:dataPostRecord or action:dataUnlockRecord. To get around it, we capture every possible action on the page UIObject by which the user could leave the field or the form. Needless to say this list is rather long, plus I've never been sure that I covered all the possibilities. I've always believed that there was a "right" way to do it which I just couldn't find. Any thoughts?

- John

 

[TonyMcGuire]

A couple of articles.


The first is a primer for the built-in RI:

http://www.thedbcommunity.com/interact/refint.htm

Roll your own RI:

http://www.thedbcommunity.com/code/refintcode.htm

Tony McGuire

http://forums.tonymcguire.com