> Further to your earlier reply, what I am wanting to do is to define a
> function which combines two integer values and a text value to form a real
> value which will then uniquely define an item matching a row in a table.
First off, when writing UDFs or Plugins, you get to pass a single string value
into the function and return a single TEXT value back. You can then convert
the text value back to REAL in R:Base if you need to, but it generally takes a
separate conversion statement in R:Base to accomplish this:
SET VAR vInput = CTXT(.vInteger1) + ',' + CTXT(.vInteger2) + ',' + .vTextInput
SET VAR vTextOutput = (@UDF('MyUDF', .vInput)
SET VAR vRealOutput = (FLOAT(.vTextOutput))
If you are storing the hash value as type REAL in a computed column is the
problem that you need to match that to other tables that contain the three
individual values in columns but not the computed column? If so, you have both
a design issue (all subsidiary tables should store only the REAL key, not the
three subvalues) and a performance issue.
If you can't redesign the application to only compute the key value in the main
table and store only the key value in the subsidiary tables, consider
duplicating the calculated column in the subsidiary tables so that you will
have indexed values to match on in all tables.
Also, consider placing the hashing logic into an R:Base stored procedure so you
can use it in multiple places without worrying about having different
algorithms in different places.
Remember that when you use a UDF or Plugin R:Base loads and unloads the dynamic
link library for EACH invocation of the plugin. So if you do
SELECT (@UDF(Filename, ColumnName)) FROM TableName
and the table has 100,000 rows, the DLL will be loaded, called, and unloaded
for each and every row. As far as I know, there is no way to preload a UDF in
R:Base (at least up to 7.1) and keep it loaded for the entire session. This is
only a problem if you are calling the UDF over and over again as in a SELECT
statement.
--
Larry
