A while back, I posted some articles which used the Support Debugging Tool and non-logging Automatic Debugger Mode triggers to "encrypt" data.

The use of the word "encrypt" was unwise as it has connotations about providing a level of security and possible compliance with various standards.

So, to more accurately describe what is happening AND to ensure there is no confusion about exactly what the example code is doing, the posts have been updated to refer to "obscuring" the data.

If you have deployed the code at any sites, please do the following:

1. Ensure that the customer is aware that the code is not secure or compliant.
    
2. Please remove the old code from the Support Debugging Tool under Setup Automatic Debugger Mode, Runtime Execute and SQL Execute.
    
3. If they would still like the functionality (understanding its limitations), then re-install the updated code from the updated blog posts.

Here are the links to the updated posts:

• Obscuring Table Data Fields using the Support Debugging Tool
   
• Update: Obscuring Table Data Fields using the Support Debugging Tool 

Note: The function used for this example ito obscure the data is a very simple algorithm built into Dexterity and is only meant to stop the data from being easily readable. It is NOT secure and does not meet any compliance standards for encryption of personal data. Use at your risk.

If you want proper encryption of Credit Card details, there are solutions from Independent Software Vendors (ISVs) for Microsoft Dynamics GP.

For details on ISV solutions, go to http://pinpoint.microsoft.com/en-US/home, on the right click on applications, then search for “Microsoft Dynamics GP Credit Card Encryption”.

Thanks

David