>>I have an app running on an NT server that periodically seems to need to be recompiled. The main user of the app calls me approximately every other week reporting that no one can save records to tables in the app. When I explored this, the #DEFINES used for some code in the DBC's stored procedure were no longer there...So the app was reporting errors that certain variables were undefined.
>>
>>These #DEFINEs are in a separate file from the DBC. This suggests to me that someone (or something) is opening the DBC, messing around, and then recompiling the DBC. Since the #DEFINEs are not available when the DBC is recompiled, errors occur for my main user in the app after this occurs.
>>
>>I have never had this occur with any other applications written using the same technique. Does this sound like a rouge user doing something, or could this kind of thing happen through some process on the network???
>>
>>I could just place the #DEFINEs inside the DBC to correct the problem, but I feel like someone is messing around with the DBC, and would kind of like to find out.
>>
>
>The problem you're encountering is that #DEFINE is resolved at compile time, not really suiable for use in a .DBC, since lots of things, including running various sorts of things that update and clean up the .DBC may force a recompile (I use the SDT Update() function in various pieces of code that check the validity of the DBC, or check to see if I've shipped out updates to tables/indexes/views, so I'm not alarmed by the behavior, and obviously, when these things happen, the #DEFINEs, in the .H file, are either not in the search path, so that any #INCLUDEs in your SPs can't find it, or if it's a compiled app, may not even be available on the system. And since I control the metadata, anything resulting from munging with the DBC at the site accidentally is fixed by the recovery code from SDT as long as when the SPs are forced to recompile, the file references in code are resolvable.)
>
>IOW, rip out the #DEFINEs that you indirectly reference through #INCLUDE and put them in line in each procedure, or make sure that the #INCLUDE is present everywhere that the #DEFINE values are referenced and put it where it can be found.

Thanks for the recommendation...I too use SDT for various tasks (Update, Reindexing, Packing, etc.), but I have never encountered this situation with any other apps written in the same way. Just didn't seem write that only one app has had this problem. The users at this site do have VFP and do open the DBC to do some tasks using the Query tool, and also run some SQL on their own. What might they be doing to trigger the need for a recompile on the DBC?

I will remove the #DEFINES, but would still like to find out why this app is behaving this way, when I have never had the problem in others.