Sybernet / Supplied Procedures Reference
Release 3.00
Oct 14, 2002

HTTP.SP_HTML_PROCMAN

This application program invokes the Sybase to Oracle translator. In some cases the translation will be "100%" correct and not only compile, but run in your first pass. In other cases you will be forced to either modify your Sybase source or the translated Oracle source.

Option	Description
Template	It is too bad, but you can't prefix your variable names with an at-sign (@). I couldn't decide on the best naming convention to use, so I left it as an option to you. If your variables names (sans the at-sign) are unique and do not match column names, then you can tell the translator to leave your variable names untouched with the following template: % Or you can force qualification with %.% which prepends your procedure name (followed by a period) to each variable name when used in an expression. Or you may not want to give up the at-sign. For this you can specify @% which causes your variable names to be double-quoted and look really ugly, but pretty much guarantees your procedure won't have any naming conflicts. The default, however, is MY_% which looks pretty good in some cases (EMPL_ID becomes MY_EMPLID), but looks pretty bad in other cases (i becomes MY_i).
Translate As	The translator will allow you to compile your procedure as either a procedure or a function. You will want to select function if your procedure's return result is used by other procedures or functions; for example, sp_cron_insert is a procedure in Sybase but a function in Oracle because its return result is important to the procedures that call it. If you select Function, you will not be able to register it with the Stored Procedure Register or with the Sybercron Register. Sybercron no longer uses your return result to determine if your procedure completed successfully (since there is none). Instead, Sybercron uses the built-in function ERRNUM to determine this. If you are compiling a trigger instead of a stored procedure, that needs to be specified as well, though I think you may be disappointed with some of the translation. I confess I didn't spend too much time on this, and although triggers are very similar to procedures, those constructs that are unique to triggers are not mapped very well (if at all).
Run Context	Author says you want to run under the context of the author of this stored procedure. This is typical for both Costpoint and PeopleSoft stored procedures which (because you are the owner) can select, delete, insert, and update any table owned by that author. User says you want to run under the context of the user that is invoking this procedure. Sybase procedures in sybsystemprocs are like this; for example, the Sybernet Interactive SQL procedure was compiled with a run context of user so that you can only see tables or execute procedures that you are allowed to touch. An interesting upshot of this facility is that when you are running the Sybernet Interactive SQL, Stored Procedure Editor, Stored Procedure Register, or Sybercron Register, you can't see anything you are not allowed to see. This is different from Sybase where although you may not touch a particular table, you can see that it exists.
Reserved Words	This drop-down list determines how reserved words and non-reserved words are cased. PL/SQL is case-insensitive, so it doesn't matter which you choose. It might matter to you because you don't want to see mixcased reserved words. You can choose from Don't Touch uppercase (reserved words are uppercase; non-reserved words are lowercase) lowercase (reserved words are lowercase; non-reserved words are uppercase) uppercase all (reserved and non-reserved words are uppercase) lowercase all (reserved and non-reserved words are lowercase) The default is "uppercase" which means Oracle reserved words are in uppercase and non-reserved words are lowercase. It's purely cosmetic, so the choice is yours.
Date To Varchar	This option determines how the translator will map datetime parameters. Yes (the default) means they are converted to varchar2 and passed to HTTP.DATETIME to create a local DATE variable. No means datetime parameters are mapped directly to DATE. You can't pass a string to a DATE variable in Oracle without also specifying the format of that date. For example, TO_DATE('Jun 12, 2001','Mon DD, YYYY') is valid, but only because I told Oracle the format of the date. When a datetime is submitted through a form screen, you can't really control what that date is going to look like. Date strings must match the current default date format (DD-MON-YY) which doesn't allow you to specify the century or the time. If your datetime parameters are really dates because they are being passed to this procedure by another procedure, then you will want to reset this option.
Tabs	As you can see the translator will insert more text than it removes. To do so while attempting to preserve your particular style of formatting, it removes all tabs from your source file, but puts them back when it is done. This option determines how many spaces a tab represents. 4 (the default) and 8 are the two most popular. If you select 0, then your tabs are not removed, but then the translator won't know how much to indent the text that it inserts.
Check	The default is NO and does no checking. When set to YES, the translator will "attempt" to compare your variable names with column names in a table. If the types don't match, you'll get a warning. Here's one now. #WARNING: @JOB_FAMILY IS DECLARED AS CHAR(2) BUT THIS COLUMN WAS DECLARED AS CHAR(6) The translator assumes that your variable names (sans the @) are exactly the same as the column name. @JOB_FAMILY is matched with the column JOB_FAMILY. If you declared your variable as something else (@JBFAM), it ain't going to work. The translator also assumes that all column names with the same name have consistent types. That is, all JOB_FAMILY columns in your database are declared as CHAR(6). The reason for this is that it doesn't know the table name, so it uses the first one it finds. PeopleSoft is consistent in this case so I think this is a reasonable assumption. Also, it will search your schema first. If it doesn't find a column by that name, it will search everyone's schema.
Equality	This option determines how the translator handles expressions of the form COLUMN_NAME = VAR in your where clause. The default is NO which means the expression is untouched. When YES, the translator rewrites this expression to have the same semantics as Sybase. The above example becomes (COLUMN_NAME = VAR OR COLUMN_NAME IS NULL AND VAR IS NULL)
Browse	You will use the Browse button to locate the source of your Sybase stored procedure. It's probably a very bad idea to point this to an Oracle stored procedure.
Translate	The Translate button translates your Sybase stored procedure to Oracle Syntax, but instead of submitting it to Oracle for compilation, the translated source is written to your browser. If you choose to edit the Sybase source instead of the Oracle source, then this is quite useful because the source is not only colorized, but each line is numbered as well. Costpoint, for example, runs on a case in-sensitive server, but Oracle is case-sensitive. Consider the expression VAR = 'Sybase' If the value of VAR is really SYBASE (upper-case) and not Sybase (mixed-case), then perhaps there is an argument to modify the Sybase source instead of the Oracle source.
Compile	The Compile button translates your Sybase stored procedure to Oracle Syntax. You might get lucky and the procedure compiles without errors. But even if it doesn't, the procedure will still reside in Oracle. You can use the Sybernet Stored Procedure Editor to extract the source and make the necessary changes. Even if it does compile (or when it does compiles), it is still your responsibility to make sure it works.

HTTP.SP_HTML_PROCMAN

See Also