Development Matters Blog

Working with Share and Branch options in VSS for Dexterity projects sometimes requires working with nested projects like on the picture below:

If we try to connect to the nested project through Dexterity, we will find ourselves in a situation that we cannot see the nested project. However, there is a way to load it, but there is no way to see it in the Projects window. Look at the following text.

Open the Dexterity project. Follow the path File -> Options -> Source Control. Click the  ellipsis near the Project Name. We are not able to see the nested projects.

Now, close the window Projects and enter the whole path Project/Project v.0.1.0 in the text field near the project name.

If we click the  ellipsis near the Project Name, the window Projects will open and we will be able to see the same list of projects as earlier. If we click the button Validate Connection, we will receive the following message:

But, this time, we do not follow this message and give up from loading data from this project on VSS. If we enter the proper name of a project as we have already done, the Dexterity will recognize it and load data from the nested project despite the message which warns us that we are on the wrong way.

During a table upgrade, we are met with the task of creating and deleting tables on SQL using Dexterity code.

The process of deleting tables requires deleting both the table and its stored procedures, but the process of creating tables does at the same time create a table and its stored procedures on SQL. Also, if we try to create the stored procedures after creating a table, the result will be failed.

The whole process of creating a table is done in one line:

open table TableName;

The following few lines will try to create stored procedures:

l_result = Table_CreateProcedures(ProductID, table CSCIVCatalogNotes);

if l_result <> 0 then

                error “Stored procedures were not successfully created for table CSCIVCatalogNotes.”;

end if;

However, if we try to create stored procedures after we create the table on SQL, we will always get the error message. The main reason is that stored procedures are already created.

The process of deleting a table from SQL requires deleting stored procedures:

local long          status;

status = Table_DropProcedures(ProductID, table NameOfTheTable);

If the value of the variable status is equal to 0, stored procedures are successfully deleted and now we need to delete the table from SQL. We can do it this way:

Local text sCode;

Local long status;

status = SQL_Connect(SQL_connection);

if (status = 0) then

                            sCode = ” use ” + DatabaseName;

                            sCode = sCode + ” drop table PhisicalNameOftheTable “;

                            status = SQL_Execute(SQL_connection, sCode);

                            {— If status is equal to 0 the table is successfully deleted. —}

end if;

status = SQL_Terminate(SQL_connection);

The whole story is important especially for a process of upgrading tables, because if we do not delete stored procedures and just drop and create tables, some of the old stored procedures can stay and mix with the new ones, so real damage can be made.

While working with Dexterity, I found myself in the situation that we had already created a few new builds and put them on the Visual Source Safe. However, the client wanted to get the build a few versions older than the previous one. Visual Source Safe does not have an opportunity to rollback some previous versions of code without losing new information. We were forced to rollback file by file and the new information had to be saved in local.

This situation could be resolved by using branching in TFS (Team Foundation Services). It allows us to support multiple releases at once. So, we can do bug fixing in some previous releases without losing the new one, which would also affect the new releases. But after some research I found out that TFS does not support connection with Dexterity and I have not found any other solution.

Do you have any ideas? Thanks.

I found a useful link for getting into naming conventions for physical names in Dynamics GP. There is a good explanation how table and field names are created in the Dynamics GP original code and we should use the same rules for new ones. You can find the article on MSDN:

 Understanding How Microsoft Dynamics GP Works With Microsoft SQL Server Continued

In Microsoft Dynamics GP, we are able to add shortcuts to the navigation pan manually.

We got the idea to improve our Merit Solutions’ Starting Project, which we use as a base for all other projects created in Dexterity, and to write code for automatically adding shortcuts of new windows to the navigation pane during the installation process. It is possible to be done using procedures from syScBarObj form. However, we came up to a problem.

When it is done manually, shortcuts are added the same moment we add them. When it is done by coding, we need to reset the Dynamics GP window and shortcuts will be shown then.

We could not find other solutions, so we agreed that the best way for resolving the problem is asking a client if they want to add shortcuts and warning them that Dynamics GP needs to be restarted before using them.

The Support Debugging Tool is a Dexterity-based suite of utilities and tools created to assist with the task of supporting Microsoft Dynamics GP.

Some examples of purposes where the Support Debugging Tool can be used are listed below:

• To identify the specific series of events which lead up to an issue or bug in the code occurring.
• To quickly and simply turn on all logging and profiling capabilities without restarting the application. This can be useful when looking at performance problems.
• To find details about dictionary resources.
• To identify resources (forms, reports and tables) causing security access issues.
• To enable and disable third party products or change the order of the products in the launch file.
• To export data from and import data to any table.
• To run SQL or Dexterity scripts without needing Dexterity or SQL Administration Tools installed.
• To capture and email or save screenshots of all open windows and a system status report.

The Support Debugging Tool is installed by copying the Debugger.cnk (self-installing dictionary), Debugger.txt (readme file) and Debugger.pdf (this user guide manual) to the Microsoft Dynamics GP application folder. When Microsoft Dynamics GP is next launched, select “Yes” to include new code. The Support Debugging Tool requires the version 8.00 Dexterity Runtime update 8.00m88 or version 9.00 Service Pack 3 or later. The Support Debugging Tool works with all builds of version 10.00.

I have been using Dexterity for a long time and find it very easy to learn and powerful for the purposes it was designed for.

Just to make life of Dexterity developers interesting, from time to time you may experience some odd code behavior. In order to overcome such cases, I recommend as much advanced debugging as possible in any situation. A few days ago I faced a problem with the “copy to table” statement.

“copy to table” and “copy from table” are recommended for usage for a variety of reasons. The most important reasons are a more readable code and compatibility with Modifier (if you copy field by field and someone extends that window through the Modifier, the new fields will not be saved nor read).

But, with the “copy to table” statement, I run into the situation where key fields of a targeted table were not copied into the table buffer even if they had an AutoCopy flag equal to true. That lead to the malfunctioning of the form which was saving all data into the same records with key values empty.

The cause of this problem is that the form had more than one window with those key fields and on each window those fields have AutoCopy flag set to true.

There are two solutions
• To set AutoCopy flag for all repetitive fields to false on all windows but one
• Explicitly define source window through command “copy from window XYZ to table AAA” (I prefer this solution)