That's similar to asking how to enforce your rule if another programmer directly sets the global. If any programmer bypasses the "system" anything can happen ... which is true for any DBMS and not just FileMan. A programmer with authority to "go around" the rules doesn't have to follow the rules. But if you're just worried about storing internal values directly, you might be able to put your logic in the cross-reference code. But I'm not sure how FM would behave if, e.g. the x-ref code set the field back to null if the logic found it was a duplicate.
In this case, put in the DD descriptions (both the field description and the x-ref description) your rule about never bypassing the input transform to insure uniqueness. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Sent: Tuesday, March 07, 2006 5:41 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] field uniqueness (key index but null allowed) That's the whole problem -- if another programmer uses a db call with internal values then the Input Transform rules would be bypassed, leading to the possibility of duplicate entries. One could provide a special API for handling that field but once again if somebody doesn't use that API you're back to the data quality issue. That's why I'm trying to accomplish this with db rules. So how does one enforce this uniqueness rule even if using DB calls with internal data values? ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
