Goodbye SL

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

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.