Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, datatypes, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications.
Ii have 14 tables of SendController each for a certain purpose. <<
That is a <verb><object> name, not an entity/table name -- appropriate
for a procedure but not a table. Have you read ISO-11179 or a book on
data modeling? And these 14 tables are completely different from a
logical view (that also means different in structure -- read Date and
Mcgovern)? You cannot have a "purpose_code" in one table?
I have a procedure for deleting controllers. I want that if a
controller is sent (i.e its id is in at least one of the tables) then
isActive=0 otherwise if the controller id isn't present in neither of
the 14 tables then delete controler record [sic] <<
Okay, you write code with assembly language style bit flags and don't
know that a row is not a record. I am now pretty sure, even without
DDL, that you have a serious design flaw.
It is a called splitting attributes; you have a single attribute and
instead of putting it into a column (columns are not fields, by the
way) you create an array of tables for each value. The result is
complex queries like this -- they are usually expensive queries and
lose data integrity.
Would you like to try again with specs? Ther are wasy to model a
class hierarchy in SQL, if that is what you are trying to do.