In order to debug using a 3GL debugger (e.g. Microsoft Visual Studio), the environment variable X_DEV needs to be defined. This has two purposes. The first is a full debug in a development environment. The second is release debug for use in deployed environments so that process dumps can be fully interpreted by support staff.
Full debug is selected by defining the X_DEV environment variable and choosing Debug Enabled. This is useful when 3rd party programming languages are used with LANSA.
Release debug is selected by defining the X_DEV environment variable and NOT choosing Debug Enabled. The resultant DLL will be the same size as if X_DEV did not exist. An extra PDB file is produced which must be kept as a pair with the DLL.
A typical situation that requires release debug is when an access violation occurs that is hard to reproduce. The end-user takes a process dump and sends it to their application's support service. The release debug files are then used to determine exactly what the program state was when the access violation occurred. This is very useful for LANSA support, even if the application developer has no intention of using these files themselves. For further information, refer to the Microsoft MSDN site: http://msdn2.microsoft.com/en-us/default.aspx and search for "Symbol Server".
LANSA strongly recommends that release debug is chosen before shipping an application to end users. It is important that the DLL and PDB files produced are kept as a set as the PDB files cannot be re-generated later, even if the source file is exactly the same. This is a Microsoft Windows restriction. Do not ship the PDB files with the application, just keep them in the event that a difficult to diagnose defect occurs.
The generated source code is also required in order to fully resolve dump files. It is possible to produce this when needed, provided the original Visual LANSA development environment is retained.
