Function Parameter

I am writing a function which will take two parameters. One the field
to be returned from a table and second parameter is the ID of the
record to be returned.

Problem is it's not returning the value of the field specified in the
parameter but instead returns the parameter itself. Is there a
function that will get the parameter to be evaluted first?

ALTER FUNCTION [dbo].[getScholarYearData]
(
-- Add the parameters for the function here
@FieldName varchar(50), @ScholarID int
)
RETURNS varchar(255)
AS
BEGIN
-- Declare the return variable here
DECLARE @ResultVar varchar(255)

-- Add the T-SQL statements to compute the return value here
SELECT @ResultVar=EXECUTE(@FieldName)
FROM dbo.qmaxScholarYearID INNER JOIN
dbo.tblScholarYears ON
dbo.qmaxScholarYearID.ScholarID = dbo.tblScholarYears.ScholarID AND
dbo.qmaxScholarYearID.MaxOfScholarYearID =
dbo.tblScholarYears.ScholarYearID

-- Return the result of the function
RETURN @ResultVar

END

Re: Function Parameter

Hi,

I would do it using a procedure as follows:

CREATE PROCEDURE GetFieldValue
@strTableName VARCHAR(250),
@strFieldName VARCHAR(250),
@nID DECIMAL(9,0),
@strResult VARCHAR(250) OUTPUT
AS
BEGIN
DECLARE @strSQL NVARCHAR(4000)

SET @strSQL = 'SELECT @strResult = ' + @strFieldName
+ ' FROM ' + @strTableName
+ ' WHERE ID = ' + CAST (@nID AS VARCHAR(9))

EXEC sp_executesql @strSQL,
N'@strResult VARCHAR(250) OUTPUT',
@strResult OUTPUT
END
GO

And then execute it in a way like this:

DECLARE
@strValue VARCHAR(250)

BEGIN

EXEC dbo.GetFieldValue 'TABLE1', 'COLUMN1', 1, @strValue OUTPUT

PRINT @strValue
END
GO

Obviously the print is just to ensure that you have the correct value.
This may not be the best way, but it's a way that works for me.

Hope this helps,

Paul

Re: Function Parameter

SQL Server (alderran666@gmail.com) writes:
> I am writing a function which will take two parameters. One the field
> to be returned from a table and second parameter is the ID of the
> record to be returned.
>
> Problem is it's not returning the value of the field specified in the
> parameter but instead returns the parameter itself. Is there a
> function that will get the parameter to be evaluted first?
>
> ALTER FUNCTION [dbo].[getScholarYearData]
> (
> -- Add the parameters for the function here
> @FieldName varchar(50), @ScholarID int
> )
> RETURNS varchar(255)
> AS
> BEGIN
> -- Declare the return variable here
> DECLARE @ResultVar varchar(255)
>
> -- Add the T-SQL statements to compute the return value here
> SELECT @ResultVar=EXECUTE(@FieldName)

This does not even compile.

The fact that you want to pass a parameter for the column name indicates
that you have a poor table design. Columns should represent unique
attributes, and normally it's not meaningful to sometimes return one
column and sometimes another.

Nevertheless, you can use the CASE expression:

@ResultVar = CASE @FieldName
WHEN 'thiscol' THEN thiscol
WHEN 'thatcol' THEN thatcol
WHEN 'thatothercol' THEN thatothercol
END



--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Function Parameter

>> I am writing a function which will take two parameters. One the field [sic] to be returned from a table and second parameter is the ID of the record [sic] to be returned. <<


You got nothing right in this code. Erland is nicer about it, but
that is real message.

1) fields and records are nothing like columns and rows. That is
basic SQL.

2) You have not looked at ISO-11179 rules for data elements. At least
get rid of that silly "tbl-" and learn why even Microsoft has dropped
camelCase. And things like a "year_id" make no sense; Years are
already unique entities and have a name; they do not need an id. You
might give them a name, like the Chinese Zodiac, but that is
reaching. But a year in the context of a student is an attribute for
attending school, graduation, etc.

Also, never put the data type in a data element name like Paul did;
This is SQL and not 1960's BASIC for a 16KB PC.

3) The whole idea of what you are trying to do is a violation of
coupling and cohesion -- remember them in your first software
engineering class? You should name this nightmare something like
"Britney Spears, Squids or Automobiles" so that people will know that
you have no idea what it does until run time.

Think for a second about how uselessly vague the name
"getScholarYearData" is. Which data?

4) If you REALLY want to learn, first get some books and courses --
you really need that SE course before any SQL or RDBMS course.

Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, data types, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications. It is very hard to debug code when you do not let us
see it.

A bad design leads to these insane and impossible to maintain kludges
you are being offered to get you out of the way. It is easier than
trying to fill in an IT education in a posting.

Re: Function Parameter

> Also, never put the data type in a data element name like Paul did;
> This is SQL and not 1960's BASIC for a 16KB PC.
>
Please can you explain what you mean by this? This procedure works
fine for me, but If there is a better way of doing something then I
would like to know what it is. I am not sure we actually need to have
a procedure like this in our system, but this is how I would have
written it if so. Any improvements would be appreciated!

Re: Function Parameter

On Apr 23, 6:04 am, paul.wr...@gmail.com wrote:
> > Also, never put the data type in a data element name like Paul did;
> > This is SQL and not 1960's BASIC for a 16KB PC.
>
> Please can you explain what you mean by this? This procedure works
> fine for me, but If there is a better way of doing something then I
> would like to know what it is. I am not sure we actually need to have
> a procedure like this in our system, but this is how I would have
> written it if so. Any improvements would be appreciated!


Don't waste your time with him. He's too busy insulting people to
offer any help. This stored procedure will be used to display
information in a form. Your code worked fine and I appreciate your
help.

In the end I decided to use an SQL statement and a subform, but was
just curious as to how I could manipulate the behavior of that
parameter. For the hate mongers please excuse my trying to learn
anything new.

I love the stuff about my table structure being poorly designed. They
know this without even seeing it. Or the naming conventions
changing. Oh sorry this database is about 10yrs old so I should go in
and start changing all the table names to make these big shots
happy.

Please if you don't have any useful information to share just move
along and keep your hateful statements to yourself.

Re: Function Parameter

SQL Server wrote:

> I love the stuff about my table structure being poorly designed. They
> know this without even seeing it.

It is not necessary to see your DDL to know much about the design.

Joe and Erland tried to do you a favor. Others like me just shook
their heads and just let it going knowing there are so many people
out there that think because they can write some syntactically
correct code they are developers.

You owe several people apologies.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace x with u to respond)

Re: Function Parameter

On Apr 28, 2:20 pm, DA Morgan wrote:
> SQL Server wrote:
> > I love the stuff about my table structure being poorly designed. They
> > know this without even seeing it.
>
> It is not necessary to see your DDL to know much about the design.
>
> Joe and Erland tried to do you a favor. Others like me just shook
> their heads and just let it going knowing there are so many people
> out there that think because they can write some syntactically
> correct code they are developers.
>
> You owe several people apologies.
> --
> Daniel A. Morgan
> University of Washington
> damor...@x.washington.edu
> (replace x with u to respond)


I can take Erland's suggestion to rethink why I am doing what I am
doing (which I had already done) because it was delivered without
malice. Joe on the other hand is just plain nasty. I can do without
his kind of help.

Re: Function Parameter

>> Please can you explain what you mean by this? <<

The ISO-11179 standards for naming data elements are based on the idea
that you name things for what they inherently are. That name is then
used everywhere in the schema.

You do NOT name them for:

1) How they are physically stored -- that means you do not put the
data type into the name. We had to do in the original versions of
BASIC because the interpreters needed that information to allocate
storage on the fly. A lot of programmers never un-learned that.

Physical locators generated by the physical storage are never
attributes in the schema. IDENTITY is never a key. We do not make
the user navigate the tables using track and sector numbers, etc. The
SQL engine is supposed to handle surrogates and not the humans.

It also means no silly "tb-" or "tbl-" to tell us it is a table
(there is only *one* data structure in SQL, duh!). And no vw-" affix
to tell us it is a VIEW (the "vw-" thing always looked like a
"Volkswagen" to me).

2) Where they are located - that means the table name is not part of
the data element name. Do you change your name from place to place as
you move around? Of course not. This practice also screws up the
data dictionary (if you do not have a data dictionary your project is
really screwed).

3) How they are used in one place -- that means no "pk-" or "fk-"
affixes. That is also silly because the same identifier that is a
FOREIGN KEY in the referencing has to be UNIQUE or a PRIMARY KEY in a
second table by definition.

The correct format is "_" in lower case
for column names. The attribute types are defined in your data
dictionary, but I have a short list in other postings.

4) A data element name does not have multiple attribute types. That
means you can have "customer_id" or "customer_type" but never
"customer_type_id" because the attribute has to be either an
identifier (unique per customer) or a type (applies to many
customers).

This is usually a newbie confusing data and metadata in his attempt at
a data model.

5) A data element name is not a single attribute type. There is no
such thing as the magical, universal "id" or "date" or "value" etc.
An attribute has to be the identifier of something in particular, the
date of a particular kind of event, the value of a known attribute as
measured on a scale, etc. It is also a sign the project has no data
dictionary because you would quickly see that these magical vague
attributes apply to automobiles, squids and Britney Spears.

"To be is to be something in particular; to be nothing in particular
or everything in general is to be nothing." - Aristotle

6) A data element name is not a dangling entity name. The data
element name "customer" by itself begs the question "what?"
--"customer_id", "customer_type", "customer_name", or what? My
favorite is assuming that "sex" means "sex-frequency" or
"sex_preference" and not "sex_code" when I get a form.

The programmer has confused a table with a file and expects context to
provide the information he was too lazy to put into the table. The
field names in a file are local to the file; the column names are
global to the schema or better yet, are global to a data model that
covers your entire enterprise or industry.

An exception to this is the use of industry standard names that are
well understood in your enterprise. For example, VIN for automobiles,
ISBN for books, etc.

7) Tables are sets and should have collective or plural names, not
singular ones. That is, "Employee" is a bad table name (exception:
you really do have only one employee); "Employee" is better;
"Personnel" is best. Collective nouns imply a set by their nature and
will not be used in attribute names, which have a singular name
because their values apply to an element in the set.

An exception to this is the use of industry standard names that are
well understood in your enterprise. But most of these will be
collective nouns.

8) Relationship tables should use a common name for the relationship
and not an invented hyphenate. For example, "Roster" and not
"StudentClass" or worse.

I you wish, I can also post a quick look at ISO-11179.

Re: Function Parameter

--CELKO-- wrote:

> If you wish, I can also post a quick look at ISO-11179.

You should even though the OP probably thinks reading and
standards are not part of the requirement for the job.

Others would enjoy reading it.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Re: Function Parameter

> I you wish, I can also post a quick look at ISO-11179.

I'm trying to fight my way through the kludge of data online to get an
overview of this myself - and I happened to come across this thread.

Yes, a quick look at ISO-11179 would be great (an indept look would be
even better ;) )... I've inherated the tblConjoinedName legacy, but
have a chance with a new ap to do things right - if only I knew what
"right" was!