Rollover Error

Kari,

Any chance you can copy/paste the text of the error?  Maybe others are different, but I cannot blow it up and read it successfully.

John

Whoops - didn't realize how small it was! Here's what the message is:

Report request cancelled due to a Datawindow Retrieval Error - Error Code: 50000, Error Text: Select Error: SQLSTATE = 42000
Microsoft OLE DB Provider for SQL Server
Error in TP_ROLLOVERN

I know nothing about rollovers, but is it possible your test environment is running on ODBC connections? 

Hmmm... That seems to imply that there is an issue running the procedure that runs the rollover report, which means that something is indeed wrong.

The most immediate thing that occurs to me to get a clearer answer would be to run that procedure with the same parameters directly from the database and see the error message given there as it would likely provide more clear details.  But then, I spend much of my time in the database, so naturally that is what occurs to me.  Is that even a possibility for you?

I probably should have mentioned in my initial post that we are RAMP hosted, so I don't think that is something that I can do.

Not 100% positive, we are RAMP hosted.

If you are RAMP hosted then I doubt Emily's suggestion is the issue.  As for the database question, that is more of a staff knowledge issue than a RAMP one.  We are also on RAMP, and most of my job is inside the database.  But if you do not have a staff member who is fluent in SQL, then access to the database would not be prudent.

Other normal thoughts regarding RollOvers:

• Do you use the price type mapping table, and if so, have you double checked it?
• Did you try paring one of the rollover sets down to the barest, just one package to one package?
• Any reason to think you might have accidentally chosen a controlled batch type?
• Was the rollover source set up correctly with the proper list of patrons?

That was always at least my starting point.

John - 

Thanks for all the insight.  I am slowly working on building my SQL fluency, but I'm not at a point where I would be able to troubleshoot things like this.

Regarding everything else, for this particular rollover set, it's a one to one package rollover with the source left blank and the mapping table is not used, and I did select a ticketing (uncontrolled) batch.

Not sure what else to check, so I'm hoping I'll get a response to my support ticket soon.

Ya... nevermind! :)

I did not even realize that you could do source-less rollovers now.  Cool!

The only other thing that occurs to me is if you made changes to your facility between last season and this one.  If that is not the case, then you are probably going to need to see if Support can help you.  At least, that is the end of good ideas I might have here.

Thanks John! When you say changes to the facility, are you talking about in the Facility Setup itself?  We did add a few seats to a screen and if I remember correct we only updated one season to reflect those changes.  I'm thinking this might be the source of the issue, I was trying to do a rollover for the season we did not update.  I'll try a different package and see if that goes through.

Yes, I was talking about in Facility Setup.  And yeah, that indeed could be related to the issue then.  The way that the seats of a facility relate to each other for rollovers is very specific and not always obvious just by looking at them.

My hope is that with the re-working of the seating map screen some of the quirkiness goes away.  But we shall see.

To add to the fun:

I tried a different rollover rest and now get this fun error message: 

The INSERT statement conflicted with the FOREIGN KEY constraint "FK_T_SUB_LINEITEM_TR_PRICE_TYPE_original_price_type". The conflict occurred in database "impresario", table "dbo.TR_PRICE_TYPE", column 'id'  

Clearly, the system does not want me to do any rollovers.  This happened for a rollover set that is using the price mapping table and for a rollover set that is just copying from previous. Double checked that all my source price types are available in the target packages, so I think it's just time to wait for Support to answer my ticket.

Probably.

The only thing that occurs to me on that is, is there any chance that you have two different price types with the same description and chose the wrong price type ID (but correct description) in the mapping table?  Unless I am misreading things, that foreign key would imply that the price type ID it is trying to assign to the new orders is incorrect in some fashion.

Hello all. Was this ever resolved? What was the root cause of the error?