Hi All,

IHAC who is testing IDS Version 9.40 FC4 on HP-UX11.0
and are in the process of upgrading 7.31 to 9.40.

Now while testing we encountered a unique situation in
which we start getting error 674. (routine name cannot
be resolved).

When we tried to call a stored procedure remotely(from
another instance on the same box) which accepts
(char,int,int) as inputs and giving("0125",1,"2") as
parameters in the stored procedure execute statement,
it failed with the error 674

while the same thing works if we do it on the instance
directly i.e., not remotely. I mean with same
parameters ("0125",1,"2")

But if we pass the parameters("0125",1,2) <see the
difference now 2 is not in quotes> to the stored
procedure while trying to execute it remotely, it
works just fine.

So is this a new feature or bug in 9.40 FC4.

Has anybody had this kind of issue while testing the
product.

Your help is appreciated on this.




__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/...otelifeengine/
sending to informix-list

"Vineet Mehrotra" <vin_us@yahoo.com> wrote in message news:cdjg85$n64$1@news.xmission.com...
>
> Hi All,
>
> IHAC who is testing IDS Version 9.40 FC4 on HP-UX11.0
> and are in the process of upgrading 7.31 to 9.40.
>
> Now while testing we encountered a unique situation in
> which we start getting error 674. (routine name cannot
> be resolved).
>
> When we tried to call a stored procedure remotely(from
> another instance on the same box) which accepts
> (char,int,int) as inputs and giving("0125",1,"2") as
> parameters in the stored procedure execute statement,
> it failed with the error 674
>
> while the same thing works if we do it on the instance
> directly i.e., not remotely. I mean with same
> parameters ("0125",1,"2")
>
> But if we pass the parameters("0125",1,2) <see the
> difference now 2 is not in quotes> to the stored
> procedure while trying to execute it remotely, it
> works just fine.
>
> So is this a new feature or bug in 9.40 FC4.
>
> Has anybody had this kind of issue while testing the
> product.
>
> Your help is appreciated on this.

In version 9.x stored procedures can be overloaded. When u type
the last parameter as "2", the engine tries to take it as a
char and since the signature of the procedure/function is char,int,int,
it fails with -674. When you send it as 2, the signature matches.
hence it executes. In 7.x version, since there is no procedure/function
overloading, regardless of "2" or 2, it always converts the last parameter
into int.

You still have a point about the same syntax working locally. So it might
very well be a bug with remote calling.

Bottomline: Don't try to fool around with procedure parameter casting. Try
to send parameters the same way they are declared.

ravi