Subject Re: [IBO] Parameter mismatch preparing TIBOStoredProc?? Bug??
Author G. Allen Casteran
G'day Helen!

Yes I compiled and committed the SP load. I tested it with an ISQL tool and
made sure that it worked. The TIBODatabase connection was indeed connected
to the SP and active.

I did some more testing and find that the TIB_StoredProc seems to pick up
the StoredProcs but TIBOStoredProc does not. It's like they don't exist.
The StoredProcName on the IBOStoredProc does not list the procs when you
drop down the list. Just empty. No matter whether I specify a DatabaseName
or an IB_Connection. Same failing results.

On the TIB_StoredProc after preparing it shows the param as an Int64 datatype.

>>Where is the aKeyCol parameter value coming from? Is it of an
appropriate data type?
>>Numeric(10,0) seems a bit odd... And how are you passing the value to
the component?

This is to match the keycol of the table, which is a generated value.
According to the IB 6 docs the generators create and Int64 value so a large
NUMERIC is the only datatype in IB that will create such a field. I would
have expected them to create an INT64 datatype, but alas no such luck.

Passing the Value is the next question on my list. In my app I am handling
the value as an Int64 value. How do I pass that to the param if the param
does not have an AsInt64 or AsLargeInt property?


> >Question 2: If I am passing an Int64 variable to this parameter, how should
> >I do it? There is no .AsInt64 or .AsLargeInt on the Param object. The Param
> >is a NUMERIC(10) to match the Keycol which is set by a generator, hence the
> >Int64 datatype.
>
>Int64 is valid ONLY in a Dialect 3 database. It is NUMERIC(18,0). You
>can pass it either
>AsInteger or simply use the .Value property and let IBO cast it.

I should probably change my key definitions to NUMERIC(18) instead of
NUMERIC(10). Still AsInteger will pass a 32-bit value. How do I pass a
64-bit value??

>If you are passing 32-bit integers, they are also AsInteger; and your
>Stored Procedure variable should be of type INTEGER, not a scaled numeric.

If I do that then I can't pass a 64-bit value that matches the datatype of
the KeyCol (primary key).

Thanks,

Allen.