• Replies 6 replies
  • Subscribers 338 subscribers
  • Views 46 views
  • Users 0 members are here
Related

Error on a new customer report

Matthew Hodge
$organization

Hi all,

I'm in the process of setting up a custom report where the code was generously lent to us. I've set the report (well, it's a utility, really) up in Report Setup but when I go to run it, I get the following message:

 

Select Error: SQLSTATE = 22018

Microsoft OLE DB provider for SQL Server

Error converting data type nvarchar to int.

 

Here's what I've checked for so far:

- I've run the actual procedure itself, and that pulls all the information I want it to.

- In InfoMaker, I tried running the report by just entering the correct retrieval arguments and seeing if that worked. It did.

 

So does that mean I'm right in assuming that the error is somewhere in Tessitura talking to InfoMaker? If that's the case, is there anything obvious I should look out for?

 

I'll keep plugging away at it, but if anybody has anything they can suggest in the meantime to try, that would be fantastic.

 

Cheers,

 

Matt

Parents
  • $organization

    Hi Matt,

    Good day.

    Are you trying to set up a infobreaker report with a datetime parameter in it?

    I had a similar problem days before.

    What happened is the infobreaker try to send something like '0' to a datetime parameter , this caused an error.

    you can catch this with sql proflier when you select the sp from infobreaker list(before the error pop-up).

     

    here is my code to prevent this kind of errors from happening:

    ALTER procedure [dbo].[LRP_BANK_PAYMENT]
    @post_no varchar(50),
    @gl varchar(50),
    @timeCheck varchar(50)
    as
    begin
    if  @timeCheck = '0'
    set @timeCheck='21:30'

    have fun

    Ben

  • $organization in reply to Ben Gu

    Thank you for your help, everyone. What it turned out to be was that something was wrong with the stored procedure call in Infomaker. I'm not sure how it ended up that way, but if you can imagine the procedure as being something like this:

     

    execute dbo.LRP_PROCEDURE NAME;1 @Parameter1 = :Parameter1, @Parameter2 = :Parameter2, etc.

    What had happened was that the colon had disappeared between the = and the Parameter name (e.g. @Parameter2 = Parameter2)

    So instead of picking up the real Parameter 2, which was meant to be an integer, it was getting the name "Parameter2" which was an nvarchar which threw the whole thing for a loop.

    Whew! . . . Now I can actually see whether the *report* does what I want it to do.

     

    Thanks everyone!

  • $organization in reply to Matthew Hodge

    Thanks for tipping me off about the Profiler as well. That was how I discovered what was going on.

Reply Children
No Data