I got this error today in one of my automated import logs:

System.Runtime.InteropServices.COMException (0×80040005): Value does not fall within the expected range.

After spending a long time checking the value that I was trying to import against the control’s Mask property and other things like that, I remembered – the value that is not in the expected range is the control name.

The offending code is something like this:

sivApp.Controls["xuser1"].Value = “ABC”

I was spending all of my time analyzing the “ABC” value, but that wasn’t the problem. It was the “xuser1″ value. At some point, my customization had changed the control name from “xuser1″ to “xduser1″, so the “expected range” was a valid control name and what I was passing in was not a valid control name.

I didn’t find anything on the knowledgebase, so I ran a SQL Profiler trace to see if I could see what was going on.  Luckily, the error happened very quickly so I didn’t have to plow through a ton of results to find what I was looking for.

Pretty quickly, I found a ROLLBACK TRANSACTION and that sounded like what I was looking for.  Just before that, the Sales Journal pre-process (4069002.exe) had run 2 stored procedures.  ADG_GLWildcard_AcctXref and ADG_GLWildcard_SubXref.  I copied the parameters passed in from the Profiler trace and tried to run them in a Management Studio query window. The first one (the Acct related one) ran fine.  The second one (the Sub related one) returned an error related to a permission problem trying to select from vs_subxref.  This seemed promising.

I looked at the SQL inside the two stored procedures and both contained this clause – WITH EXECUTE AS ’07718158D19D4f5f9D23B55DBF5DF1′.  This tells SQL not to run the SQL code with the calling user’s permissions, but this specified user instead.  (The long numeric string beginning with 0771 is a special login that Dynamics SL creates on your SQL Server when you install SL.)

Inside ADG_GLWildcard_SubXref, there was a SELECT statement querying vs_subxref.  I check that view and the 0771… user didn’t have SELECT rights to the view.  I added them and tried the report again and it ran fine.

Even though I had solved the problem, I was curious now.  I looked inside the ADG_GLWildcard_AcctXref.  In parallel fashion, it had a SELECT statement querying vs_acctxref.  I went to go see if I needed to fix permissions on it as well, and was surprised to find that it didn’t exist in the database.

I went back to the stored procedures and realized that the SELECT statements were actually inside a string, like this:

select @Query = “select …”

execute (@Query)

There was also a comment that said they were doing this so that the procedure would compile even though the view many not exist.

I understand that from a SQL point of view, but that was the first I had heard of SL doing it this way.  I looked at the properties of the vs_subxref and – sure enough, it was just created a couple of days ago.  We haven’t done any upgrades there recently, but I had just done a Rebuild security to fix up some new stuff I had added to the database.

I have no idea why the vs_subxref wasn’t there originally, why vs_acctxref isn’t there now, or why the permission wasn’t created correctly. If anyone can shine any light on that, please comment.

I think the problem was that client had customized the OM Invoice (40680.rpt) and that file had been living in their Usr_Rpts folder for some time. (The file date was in 2006.)  I think that the custom report had been saved with a previous version of Crystal.  Even though that customized report worked fine for normal Invoice printing, for some reason when Application Server tried to run the report to export to PDF – it failed.

When I opened the custom report in the version of Crystal that SL currently uses (version 10) and saved it (and fixed it up – see this post for more details), the email attachments generated valid PDFs after that.

“The database table “GLTran” cannot be found. Proceed to remove this table from the report?”

even though GLTran (or whatever table name is in the error message) is in the database.

I have found this to be usually caused by Crystal  using Fully Qualified table names.  If you click “Show SQL Query” (or run a SQL Profiler trace while the report is running), you may see entries like ”select * from databasename.dbo.GLTran”, instead of “select * from GLTran”.  The databasename may be the name of the SQL Server used when the report was originally written, which is usually not a server on your network.

In older versions of Crystal Reports, you could edit the SQL query in this dialog box to get rid of the database name, but in Crystal Reports 10, the SQL query dialog is read-only.

The way to do this in Crystal 10 was not intuitive to me, but here’s what you can do.  From the Database menu, choose Set Datasource Location.

Click the Overridden Qualified Table Name line and a textbox will appear to the right.  In that textbox, type the table name, just as it shows in the Table Name line.  (Account in this example.)  Do this for each table in the report and click Close.

Putting a value in the Overridden Qualified Table Name textbox seems to tell Crystal to use what you typed there for the table name instead of the Fully Qualified table name.

Save your changes and you should be able to Verify Database without getting the errors any more.

I had manually edited the FRx32.CFG file to update the path to the SysData directory.  The relevant section looks like this:

[SYSDATA]
Directory=\\servername\SysData\

Turns out the trailing backslash is very important.  I had set it to something like this:

[SYSDATA]
Directory=\\servername\SysData

By using Process Monitor from Microsoft’s SysInternals page, I was able to find that FRx was looking for \\servername\SysDataFRxRpt32.tpl, instead of \\servername\SysData\FRxRpt32.tpl.

So, if you get this error message, it could be one of the things in the Knowledgebase, or it could be that you just left off a backslash.

(Minor side rant – the Related Searches on the side listed 4 variants of “could not route report Application Server”.  Seems like somebody at MS could find phrases that people are searching for that don’t have any results and post something relevant. But I digress…)

I looked further back in the Application Server log and found this error from when the AppServer was started – “General CDO (Collaboration Data Objects) error. Routing will be disabled for this server. 429″  I knew that 429 was frequently the error message given when a COM object couldn’t be found in the Registry.

So I did some CDO searching and found this – http://www.microsoft.com/downloads/en/details.aspx?familyid=2714320D-C997-4DE1-986F-24F081725D36&displaylang=en.  Starting with Outlook 2007, CDO is not delivered as part of Outlook but is a separate download.  Once I downloaded this, Application Server started sending the messages.

I also found this – http://blogs.msdn.com/b/deva/archive/2010/01/19/outlook-2010-why-cdo-1-2-1-not-supported-with-outlook-2010.aspx, which says that CDO won’t work with 64 bit Outlook 2010 so keep that in mind when you’re deciding where to run Application Server.

ROI

Sometimes it makes sense to bypass this and just have a user click a button on a screen and the report prints immediately (sometimes called “Quick Print” mode).

To do Quick Print, you still call ROI, but pass some parameters to it to tell it to go ahead and print (or print preview) the report without appearing to prompt the user for more input.

The basic syntax is:

ROI.exe 12345/RUN Fmt/FORMAT /PSCRN

where 12345 is the 5 digit report number that you want to run and Fmt is the format

In the Report Control Maintenance screen above, the Trial Balance report is pulled up (Report Nbr 01610).  The Combined Totals format uses 01610a.rpt and the Debit and Credit Totals uses 01610b.rpt.

If you wanted to print the Debit and Credit Totals format of the Trial Balance report, you would call:

ROI.exe 01610/RUN 01610B/FORMAT

This would print it directly to the default printer.  If you wanted to do a Print Preview instead, you would call:

ROI.exe 01610/RUN 01610B/FORMAT /PSCRN

If you wanted to add a WHERE clause filter (similar to adding lines to the SELECT tab of the ROI screen), you would use the /WHERE parameter. (Use the SELECT tab to see the exact field names.)

ROI.exe 01610/RUN 01610B/FORMAT vr_01610b.accthist_acct=’1010′/WHERE

would filter the report to show only Account ’1010′ values.

There are more ROI parameters available, but this is a good start. For more details, consult the ROI user guide (sl_roi.pdf in the User Guides folder).

To call from the SL SDK (formerly VB Tools), use this syntax:

Call CallApplicWait(“ROI”, “01610/RUN” + PRMSEP + “01610B/FORMAT”  + PRMSEP + “vr_01610b.accthist_acct=’1010′/WHERE” + PRMSEP + “/PSCRN”)

To call from a customization, use this syntax:

serr1 = Launch(“ROI.EXE” + PRMSEP + “01610/RUN” + PRMSEP + “01610B/FORMAT” + PRMSEP + “vr_01610b.accthist_acct=’1010′/WHERE” + PRMSEP + “/PSCRN”, True, True, 0)

The SL SDK project template sets the TargetCPU to “AnyCPU” by default, which means it will run as 64-bit on a 64-bit system.  SL programs have to run in the WOW64 subsystem on 64-bit systems so you need to change this setting to x86.  You can find it on the Compile tab of the Project Settings page (click the Advanced Compile Options button).

If you haven’t converted all of your (or your clients’) old VB Tools applications – you need to keep VS 2005 around.