Never have a field name be the same as the table name in which the field resides.
Is doing so asking for all kinds of problems? Not in my experience. For 20+ years my breaking this rule in a large complex app never caused a single problem–until a few days ago when I used a Copy Records operation on a table named “Funded” to create a slimmed down temp table I named “Funded_tmp”. The problem arose because the Funded table has a date field also named Funded and the latter is used in a calculated field rule with another date field. The problem is that although “Funded” is a field in the new table, in the new copied field rules the field is named whatever the new table name is, e.g., “Funded_tmp” (or “Zztop” if I named the new table Zztop). The same thing happens if I simply duplicate the table via the A5 Duplicate operation. Sadly it is way too late to simply change the Funded table name or the Funded field name. In a large complex app doing so would be an enormous project, though possibly one of Cal Locklin’s utilities might help in such an endeavor (Cal’s utilities have saved me an enormous amount of time over the years–thanks Cal, if you are still lurking around).
Of course it would be easy to correct the field name in the copied over field rules. However, I wanted the copied table to be a temporary table that would be recreated weekly with the saved copy records operation. Possibly a bad approach anyway, but that was my original thought. Obviously I don’t want to have to edit field rules every time the saved copy records operation is run.
Although I have not done it yet, I assume one easy way to deal with this problem would be to use an append to produce my weekly version of the temp table, after fixing field name in the field rules of the initial copied table created by a copy records operation.
Is this a bug? I suppose so. But Selwyn and Cian have looked at the code involved in a fix and determined that a fix would be “very risky”. So a fix is not going to happen, at least not in the near future. Since in Alpha Five there are lots of ways to skin a cat, I’m fine with cat skinning.
Is doing so asking for all kinds of problems? Not in my experience. For 20+ years my breaking this rule in a large complex app never caused a single problem–until a few days ago when I used a Copy Records operation on a table named “Funded” to create a slimmed down temp table I named “Funded_tmp”. The problem arose because the Funded table has a date field also named Funded and the latter is used in a calculated field rule with another date field. The problem is that although “Funded” is a field in the new table, in the new copied field rules the field is named whatever the new table name is, e.g., “Funded_tmp” (or “Zztop” if I named the new table Zztop). The same thing happens if I simply duplicate the table via the A5 Duplicate operation. Sadly it is way too late to simply change the Funded table name or the Funded field name. In a large complex app doing so would be an enormous project, though possibly one of Cal Locklin’s utilities might help in such an endeavor (Cal’s utilities have saved me an enormous amount of time over the years–thanks Cal, if you are still lurking around).
Of course it would be easy to correct the field name in the copied over field rules. However, I wanted the copied table to be a temporary table that would be recreated weekly with the saved copy records operation. Possibly a bad approach anyway, but that was my original thought. Obviously I don’t want to have to edit field rules every time the saved copy records operation is run.
Although I have not done it yet, I assume one easy way to deal with this problem would be to use an append to produce my weekly version of the temp table, after fixing field name in the field rules of the initial copied table created by a copy records operation.
Is this a bug? I suppose so. But Selwyn and Cian have looked at the code involved in a fix and determined that a fix would be “very risky”. So a fix is not going to happen, at least not in the near future. Since in Alpha Five there are lots of ways to skin a cat, I’m fine with cat skinning.
Comment