**"Unable to Open the Company File" error converting to 2014**

If you are receiving the error “Unable to open the company file” while trying to convert your data file from a previous version of Sage 50 to the 2014 version it could be caused by a firewall or antivirus software.

Please consult article 16353 in our knowledgebase ( http://bit.ly/GzI35i ) which can be found at na.sage.com/sage-50-accounting-ca and clicking on Get Support under the Support menu in order to find solutions.

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

  • in reply to dreolf

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

  • in reply to Richard S. Ridings

    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.

  • in reply to dreolf

    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.

  • in reply to Richard S. Ridings

    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.

  • in reply to dreolf

    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.

  • in reply to Smith and Co

    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.

  • in reply to dreolf

    Hi,

    I created 2 data files. One by Simply Accounting 2012 and one by Sage 50 2013. In both data files, I tried to set up Ralph as one of the users and (X”7’rY:Q) as the password. The maximum characters I could use for a password is 7, but I still included “ : ; ‘ in the password for testing. For the one created in Simply Accounting 2012, I had no problem to convert it to 2013 and then 2014. For the one created in Sage 50 2013, I had no problem to convert it to 2014.

    When we encounter conversion issue, doing a password reset, which removes all the user and sysadmin password, is one of our troubleshooting steps. The reason to do that is to confirm the table for users is not corrupted. If after password reset is done, there is still a pop-up window asking for password when opening the data file, it means the user table is corrupted. This is one of the reasons for conversion problem, and data repair is required at this point.

  • in reply to Smith and Co

    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.

     

  • in reply to Keith L

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

    http://xkcd.com/327/

  • in reply to Greg Goss

    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.