Development Matters Blog

SharePoint offers a very good object model which allows a developer to achieve just about anything. But what happens in situations when the developer must achieve certain functionality, but his or her code is not running on a server hosting SharePoint? That’s where the SharePoint Services step in.

Anyone who has tried to manage content in SharePoint using SharePoint Services knows that it can be a very challenging task. A lot of functionalities are limited, or don’t exist at all. Some of them are very basic and it can be a real mind cracker when it comes to the development of more complex functionalities. For example, there is no service that provides the method to delete a web site – a quite extraordinary fact, if I may add. Of course, the developer may develop a custom web service and use it for his or her purpose. However, sometimes a client requires the development of an application which is not allowed to add anything to the server machines. When that happens, the only tool left for the developer to use is the existing coding arsenal and his or her wit.

One of the very common and basic functionalities that may arise in the never ending list of client requirements is to develop a code which creates SharePoint sites. This should be rather easy, right? Well, not quite so. On this MSDN page you may see the list of all available web services. A web service websvcSites may appear tempting judging by its name, but it deals with the site content migration and site templates information. The websvcAdministration web service “provides methods for managing a deployment of Windows SharePoint Services, such as for creating or deleting sites”, as stated on the page. Unfortunately, by the term sites the documentation actually refers to site collections, thus our problem still remains unsolved.

The solution, believe it or not, lies in the web service called websvcMeetings. This service contains a class Meetings with a method CreateWorkspace. The purpose of this method is to create SharePoint meeting workspaces. It may seem odd to use such a method, because we are not actually trying to create a meeting workspace, but a site instead. The key lies in one of the method arguments – site template. By providing a site template other than the meeting workspace template, the method will create a corresponding site. This small trick extends the purpose of the method and solves the challenge of creating SharePoint sites using SharePoint web services.

The complete list of SharePoint’s default site templates can be found on this page. For custom templates, the developer should provide the name of the site template file which has been previously uploaded to the site collection’s site template gallery.

There are a few disadvantages with this method. For example, there is no option to set the permissions inheritance or whether the new site will contain the top navigation bar from its parent site. Actually, there are no SharePoint web services for the top navigation what so ever. This and many other disadvantages are eagerly expected to be implemented and enriched in the future releases of SharePoint platform.

During a creation and compilation of a Visual Studio project, more files are created in the Debug folder apart from the main output exe file.

They are results of the hosting process feature that was introduced for the first time with VS2005.

Hosting process file, with extension .vshosts.exe, serves main three purposes:

• Improving debugging performance
• Enabling partial trust debugging
• Enabling design time expression evaluation

There are more files created with the vshost file for the Visual Studio project:

• .pdb or the Programm DataBase that contains debug symbols
• .vshost.exe.manifest that contains mostly dependencies on libraries

Also, notice that these files shouldn’t be deployed with the application you finished or run directly.

It’s possible to disable generation vshost files under project settings -> Debug options -> Enable the Visual Studio hosting process checkbox.

You can find more information about the advanced debugging features in a MSDN article.

Recently I received a request from a customer to join a transferring order to an invoice and print a packing slip form after transferring the order to the invoice on the SOP Entry form. This form has already been modified and some processes have been added to it through triggers. At first, it looked like a small request, but after the first testing process I realized that it worked correctly only in simple situations. The main problem was that the original print button of the Dynamics GP window needed to be in focus before it is called. When a few operations which call different windows are joined, the focus can be lost because of the delay of opening windows or printing reports. There are also some unexpected windows which pop up and stay open, disturbing some of the following operations.

Another problem appeared when I tried to debug the code I wrote. During debugging process it worked worse than in the previous situation. Using the debugger, the focus is always kept on the debug script and none of the focuses can be reached, which means that none of the reports can be printed.

The main problem was printing reports from different forms. We needed the possibility to join one printing report from one form to another printing report from a different one. There is a small delay between the moment when options for printing are chosen and the moment of printing the report, especially if the screen is chosen for report destination. In that case, the second window already gets a focus on the print button when the first report starts to be printed. Focus on the second window is lost so the printing and processes added to that window through triggers would not be done completely.

In such situations, the only way I found to be efficient is good knowledge about processes we are working with. We need to count every possible situation which can happen during the process we need to implement, which is in most situations pretty complicated and sometimes impossible.

On a recent project I was on, we needed to access areas of Dynamics GP that were protected with a system password. However, we didn’t know the password on that particular environment, so I needed a way to reset it. I looked up for a solution and found an interesting answer.

I know that the system password is stored in SY02400 table and that this should be my point of interest. The query should be something like ‘UPDATE DYNAMICS..SY02400 SET PASSWORD =’. However, the interesting part is how to set the password to blank. The code segment “0×00202020202020202020202020202020″ represents “Blank” string in binary.

Therefore, in case you forgot your system password, just execute this query:
UPDATE DYNAMICS..SY02400 SET PASSWORD = 0×00202020202020202020202020202020

During my work with a temporary table linked to the scrolling window, I came across a few problems. The first one was using the temporary table in pass through SQL code and the second one was the range of scripts and forms where the records from temporary table could be reached. I will explain the situations through the example below.

The mxCustomerContactsTempTable is a dexterity temporary table linked to the scrolling window. All necessary data for the mxCustomerContactsTempTable table are loaded from the mxCustomerContacts table, but this table needs one more field - ‘Customer Name’ – to be filled. As we have a ‘Customer Number’ in the mxCustomerContactsTempTable table, we can load data from table RM_Customer_MSTR table. If we go through the table record by record, lookup will be pretty slow. The better idea is to use the pass through SQL code.

Instead of using physicalname(table mxCustomerContactsTempTable) for retrieving a table name, we use the command Table_GetOSName(table CustomerContactsTempTable) for retrieving a name for the temporary table. The previous command will return only TEMP as a physical name and SQL would not recognize it.
The problem can occur if we have global script with pass-through SQL code and form which use that table by calling this script. In that case, records in the table will not be recognized and script will work with the empty table. The better option is to put all code related to temporary table in the same form. This way the script will fill the table with all needed data.