SEO

Hi,



Can I pass table names / column names as parameters to a procedure ?? If
no, is there any solution to achieve the same affect ?



Regards,

Romil


--
Posted via http://dbforums.com

Well, yes. At least according to the question that you have asked.

The real question is what can you do with the parameters that the procedure
receives. Is this a procedure that you have written or will modify/write?
If "yes" then what you can do in the procedure is likely to depend upon the
ASE version. (Then again, you haven't stated as to whether you mean ASE or
ASA.) If "no" then you are limited by the capabilities of the procedure.

Could you provide some more details? (Server type, version, intent.)

"romil" <member36316@dbforums.com> wrote in message
news:3264307.1061379892@dbforums.com...
>
> Hi,
>
>
>
> Can I pass table names / column names as parameters to a procedure ?? If
> no, is there any solution to achieve the same affect ?
>
>
>
> Regards,
>
> Romil
>
>
> --
> Posted via http://dbforums.com

>> Can I pass table names / column names as parameters to a procedure
?? If
no, is there any solution to achieve the same affect <<


The short answer is use slow, proprietrary dynamic SQL to kludge a
query together on the fly with your table name in the FROM clause.

The right answer is never pass a table name as a parameter. You need
to understand the basic idea of a data model and what a table means in
implementing a data model.

1) This is dangerous because some user can insert pretty much whatever
they wish -- consider the string 'Foobar; DELETE FROM Foobar; SELECT *
FROM Floob' in your statement string.

2) It says that you have no idea what you are doing, so you are giving
control of the application to any user, present or future. Remember
the basics of Software Engineering? Modules need weak coupling and
strong cohesion, etc.

3) If you have tables with the same structure which represent the same
kind of entities, then your schema is not orthogonal. Look up what
Chris Date has to say about this design flaw.

Go back to basics. What is a table? A model of a set of entities or
relationships. EACH TABLE SHOULD BE A DIFFERENT KIND OF ENTITY.

What a generic procedure that works equally on automobiles, octopi or
Britney Spear's discology is saying that your applications a disaster
of design because you have:

1) failed to put all items of the same kind into one table. Chris
date calls this orthogonal design, and I call it attribute splitting.
Common example, 12 identical tables, one for each month, with the same
information them instead of a single table with a temporal attribute.

2) failed to tell the difference between data and meta-data. The SQL
engine has routines for that stuff and applications do not work at
that level, if you want to have any data integrity.

Yes, you can write a program with dynamic SQL to kludge something like
this. it will last about a year in production and then your data
integrity is shot.