I use UniVerseSQL a lot. The absence of the equivalent of TSQL's Replace() function was a handicap so I wrote a wrapper function for BASIC EREPLACE() and added it to the Global Catalog. It works fine but the call is a little messy.
EVAL 'SUBR("-REP.CHARS", attribute, "somestring", "anotherstring", 1, 1)'
I'm curious if there is something I can put in the VOC to allow it to be called using just a VOC name and the arguments like the native UniverseSQL functions.
------------------------------
Greg Clitheroe
Rocket Forum Shared Account
------------------------------
Well the obvious approach for me would be to write a BASIC program. Get the command that you typed in from @SENTENCE, then parse the arguments from that, and finally call your subroutine with everything in the right place. CATALOG the program, and you are done.
But, thinking about it some more, what you really want is a function that you use within the SQL statement, and that is something totally different. Your current approach is fine, and clearly works. It is just a little awkward.
You could use a variant of my suggestion above. Write a program called say: SQLREPLACE and get it to accept a syntax like this:
SQLREPLACE attribute string1 string2 : sqlstatement
Somewhere in the SQL statement, you would have a marker like REPLXXX. The program would essentially take the parameters from the first part of the sentence, and build them into the EVAL you are currently doing, and insert that into the SQL statement in place of the token. Finally, you can execute the statement.
Note that I used a colon to denote the end of the parameters and the start of the SQL statement. That means that you can make the number of parameters variable, and use default values if they are not present.
Something to think about ...
Cheers,
Brian
Well the obvious approach for me would be to write a BASIC program. Get the command that you typed in from @SENTENCE, then parse the arguments from that, and finally call your subroutine with everything in the right place. CATALOG the program, and you are done.
But, thinking about it some more, what you really want is a function that you use within the SQL statement, and that is something totally different. Your current approach is fine, and clearly works. It is just a little awkward.
You could use a variant of my suggestion above. Write a program called say: SQLREPLACE and get it to accept a syntax like this:
SQLREPLACE attribute string1 string2 : sqlstatement
Somewhere in the SQL statement, you would have a marker like REPLXXX. The program would essentially take the parameters from the first part of the sentence, and build them into the EVAL you are currently doing, and insert that into the SQL statement in place of the token. Finally, you can execute the statement.
Note that I used a colon to denote the end of the parameters and the start of the SQL statement. That means that you can make the number of parameters variable, and use default values if they are not present.
Something to think about ...
Cheers,
Brian
Thanks for the suggestion. However it seems that is just replacing the SUBR() function with another.
I was hoping to make my function behave like a Keyword straight from the command. I can see that Keyword VOC entries just have a number which is presumably referring to something in the proprietary Universe code. It is a pity they don't expose something that allows users to set up code for keywords.
------------------------------
Greg Clitheroe
Rocket Forum Shared Account
------------------------------
Thanks for the suggestion. However it seems that is just replacing the SUBR() function with another.
I was hoping to make my function behave like a Keyword straight from the command. I can see that Keyword VOC entries just have a number which is presumably referring to something in the proprietary Universe code. It is a pity they don't expose something that allows users to set up code for keywords.
------------------------------
Greg Clitheroe
Rocket Forum Shared Account
------------------------------
As I understand it, RetrieVe uses the numbers associated with keywords internally rather than the keywords themselves. This lets the whole language be converted to another language (French, Spanish etc) by simply copying the English keywords to appropriate words in the new language.
And that gets to the heart of the issue for you - because RetrieVe HAS to know what each keyword (number) does. It is all very well creating a new keyword, but internally, RetrieVe doesn't know what it does.
You are really looking for a "plugin" for RetrieVe, but it isn't built that way.
Cheers,
Brian
------------------------------
Brian Speirs
Senior Analyst - Information Systems
Rush Flat Ltd
Wellington NZ
------------------------------
