I had this problem. Article 16353 was not helpful. In our case, it turned out the problem was illegal wildcard characters in a user's password. To confirm that you have this problem and to determine which user account is at fault, look in the .SAJ folder of the company file you're trying to convert. There will be a conversion log file in format YYYY-MM-DD-HH-MM-SS.txt. Look at the tail end of the file. If you have the problem, you'll see something like this:

11/4/2013 2:45:14 PM: CREATE USER 'Ralph' IDENTIFIED BY '<password>'
11/4/2013 2:45:14 PM: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'vT:'' at line 1
11/4/2013 2:45:14 PM: Close database connection to the file

Change the user's (in this case, Ralph) Sage password to something simple and rerun the conversion. Your problem, at least with this user, should be gone.

Interesting that we didn't have this problem converting the same company files with the same user/password in previous versions, just 2014R1.

dreolf, thanks for the update.  Do you mind telling us what the "illegal" character(s) are?

As it turns out, the password contained a double and a single quote plus a colon (eg, X”7’rY:Q). I doubt that the colon is a problem. It looks like the Sage conversion logic to escape the quote characters resulted in a bad SQL statement.

SQL statements are based on text.  Double quotes are usually used to distinguish specific text.  So are single quotes.  So unless the programmers accounted for it in the conversion utility in the new version, I can see it crashing.  This is the first time I've ever heard of anyone using them in passwords before.  I've seen a password like !@#$% but not ":;'.  Personally I would stay away from those special characters in passwords that are not above the numbers on the keyboard because they have a special meaning in SQL.

The reason I asked was so that when the Tech staff read this, they can talk with R&D and let them know people use those characters.

Thanks. I believe the password was generated by the Simply user setup tool. The user did not select that password. In any event, the company files containing that password have passed through the conversion process through many releases including 2010, 2011, 2012 and 2013, without an incident. Something has changed in their conversion process and they need to fix it.

I had a problem when clicking on a chq nbr in an A/P report where a box came up with Data Not Found - the problem was traced back to me using a single quotation symbol in the Chq Nbr. Once the quote symbol was removed then there was no problem in clicking on revised chq nbr and having the chq open up.

So I am now staying away from using quotes such as Rec'd etc.

I had a problem when clicking on a chq nbr in an A/P report where a box came up with Data Not Found - the problem was traced back to me using a single quotation symbol in the Chq Nbr. Once the quote symbol was removed then there was no problem in clicking on revised chq nbr and having the chq open up.

So I am now staying away from using quotes such as Rec'd etc.

Oh - by the way - this was in the 2013 Sage50 Acct Edition - but I understand that it will happen in the 2014 version as well.

HI Smithco,

Thanks for bringing that up.

We do have an article about some other reaaons for no data to report when drilling down in an aged detail report.  Although the article is using receipt as an example, it also applies to payment.

There is no data to report when drilling down on payment in the customer aged detail report.

For those who haven't seen it before, here's a cartoon about SQL inputs.

http://xkcd.com/327/

Yes, that's kind of what I was talking about, just a little more extreme than I was thinking.  But I do expect that Sage has taken care of injection attacks properly.