Goodbye SL

May 17, 2012 6 comments

I’ve been threatening to do it for years but this is finally the year. At the beginning of 2012, I sent my Dynamics SL clients a letter saying this was the last year I was going to support the product.

For years I’ve made money off a product that I basically hate.  I knew a lot about it from working with it for years but it constantly makes me beat my head against the wall.  In my opinion, Solomon painted themselves in the corner with the SWIM architecture many years ago and have just been milking a cash cow ever since.

Well – I’ve finally gotten up the courage to burn this particular boat and turn my attention to my new startup – Circlebox.  I’m leaving this blog up in case any of the information helps anyone, but don’t plan on updating it any more.

To all of you still working with Dynamics SL – good luck!


Debugging Dynamics SL Object Model code

November 2, 2011 Leave a comment

I have made this mistake multiple times and it just cost me about 2 hours of debugging time so I thought I’d post it here in hopes of saving someone some time in the future.

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

System.Runtime.InteropServices.COMException (0x80040005): 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.


Dynamics SL – Error 20201 when printing Sales Journal

A client sent me a message today saying they were getting an error message when trying to print the Sales Journal today.  The message number is 20201 and the error message begins with something like  “…kernel is not able to use sql server cursor functions…”

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.

Dynamics SL Quick Send feature – bad PDF attachment in Email

While setting up the Quick Send feature for a client today, I ran into a problem. We had set up certain customer’s to get their OM Invoices emailed as a PDF attachment.  The emails that were sent from Application Server had an attachment whose file name had a PDF extension, but the file size was only 230 bytes – much too small to be a valid PDF file.

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.

Crystal Reports – tables not found during Verify Database

June 18, 2011 5 comments

If you try to do a Verify Database on a Crystal report used by Dynamics SL, you may get an error message like this:

“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.

The Specification set template file (FRxRpt32.tpl) is missing from the SysData directory

Got this error after installing an FRx Service Pack for a client today.  After searching the PartnerSource knowledgebase and eliminating all of the causes detailed there, it turned out to be a self-inflicted wound.

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


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


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.

Dynamics SL – “Could not route report” error in Application Server

May 31, 2011 1 comment

Today I was setting upApplication Server to send Quick Send emails for a client.  I wasn’t getting the emails when I noticed this error message in the Application Server log – “Could not route report”.  I went to PartnerSource and search on that but didn’t get any SL related posts.

(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 –  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 –, 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.