Licence Maintenance Key not Present in Dictionary

Further to the above, I have applied the same licence key to an earlier build (2021.213.200.8950).  The licence key works fine here.

This implies that the issue is not related to the licence key but something about build 2022.114.203.2690?

Hi Chris,

Thanks for following up - really appreciate it 😀. 

This issue isn’t resolved and is a becoming a bit of a major for us.  We have 4 clients that we can’t properly service because, since they upgraded to 2022,  we are so far unable to set up local dev environments with data from a recent snapshot.  We have multiple support requests in with MYOB (the Australasian brand of Acumatica) but not much feedback or solutions at all.

Over the last 4 weeks, since the initial post, we have learnt more from our own trial and error (aka clutching at straws) testing  which we have spent 30+ working hours on.  The below details what we have tried and learnt since the initial post.

SQL Server

The issue seems to be confined to local instances deployed over SQL Server. 

• We can do an install without data and the problem isn’t there.  As soon as you add data  (be it test data as part of the install, or imported from a snapshot post install), the installation cooks itself and you can’t do anything related to a license (user security, unable screens via CS10000,...).  This is on instances without any customizations applied.

• We have checked that we have the right versions of things running based on this link https://help-2022r1.acumatica.com/Help?ScreenId=ShowWiki&pageid=a8d5d39d-513a-4f93-b484-a95eb33103a1

• We have tried deploying to three separate machines to try and rule out an environment issue on an individual PC.  All of these machines work fine on 2021 builds but have the exact same issue on 2022

• We have tried a variety of License Keys and have requested new ones from MYOB support just in case it’s license key related.

MYSQL

We have also run some testing on MySQL.  However mySQL is relatively new to us and we’ve been experiencing some unwanted learning and development pain (we strongly to prefer to develop on SQL Server as that is what we know, and are only resorting to MySQL due to no solution to 1 above and the fact that our clients patience is running thin).  

• When we deploy on MySQL we don’t seem to have this issue, but we have different ones 

• On mySQL we get 2 install errors due to collation issues that initially we chose to ignore rather than resolve.

• Subsequent development on MySQL hasn’t gone that well.  Simple customised DAC’s seem to be created with incompatable types (both C# and BQL), and we get cast conversion errors .  I suspect that this is related to the collation errors we chose to ignore, but am not 100% sure.  The developer training is based on on SQL Server, so there may be a few tricks on MySQL we don’t know about?  We have subsequently abandoned the idea of doing any further development on MySQL until we have worked out what is causing this.

• We have started researching how to solve the collation issues in MySQL.  Found the following link where someone else had the same issue 

  However, this post doesn’t provide the solution, just that Acumatica support provided a workaround, but not what the work around actually was.  I understand how collation works on SQL server, would assume it is similar in MySQL, but haven’t worked out how to resolve the install errors as of yet.  I also don’t actually know if resolving the install errors will solve the cast conversion/incompatible type problem.  Being new to MySQL there might be something unrelated causing this.

So overall we’re not having a fun time and are more than slightly frustrated.  We were tracking along completely fine until our clients started upgrading to 2022. We need to get back into that space.

Thanks for any and all help, and thanks for being proactive!

John.

PS: The Acumatica dev forum is a great learning resource.  Have been reading the articles looking to pay it forward and help someone out on a problem I actually know the answer to.

Thank you for sharing the update with the community @JWS539 !