Well I don't think that would be reasonably complex to do. I mean the SQL is not something they would want executed when they enter it. It's part of a "site"'s settings and the SQL is being run when I "export" data for that "site".

I guess I should have given more background information. The project is a web based systems that lets you post job ads to many different sites at once (Monster, HotJobs, AJB, ...). It bends backwards to simplify the users' task. It first asks for the "common" fields (except those that are not being used by any of the sites) and the for the site specific ones. Where it makes sense it prepopulates the site specific fields with some data extracted from the common fields. Later on it creates files with batches of jobs for each particular site and sends them.

Sometimes the "prepopulation" rules are rather complex and sometimes I have to mangle even the data entered into the site specific fields to suit the site's twisted requirements. There are special actions predefined for the prepopulation, but to prevent myself from going crazy from having to create hundreds of different actions I allow the admins to enter a piece of SQL that massages/combines the data as necessary.

The code is then run inside the stored procedure that returns the entered/computed value of a field either when showing the fields to a user or when creating the batch file. And the code needs to be able to read the values of other fields and/or some other job related information.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature