Wünder Fodder

SQL Select Changes in Version 9 of Windward Reports

In all previous versions of Windward Reports Windward performed a simple string substitution of a ${var} into a select. Windward handled special characters like ' in the variable but otherwise did a straight substitution. This has worked very well. But in our effort to improve Windward we have made the following change for SQL selects (there is no change for XPath selects).

The ${var} in a select is replaced with a parameter and we then use setParameter() to set each parameter in the select. So the select "select * from orders where date > ${req_date}" becomes "select * from orders where date > ?" and there is then a call to setParameter(0, getMapVar("req_date"));

Windward uses the date example on purpose because this was the main reason for this change. Every database vendor uses a slightly different way of setting the date in the select string. Rather than having to know that syntax and enter it correctly, this way you just set the variable. But there is a very important thing to take into account in this change.

This new approach will break your templates.

At present your selects are of the form "select * from employees where name = '${name}'". That will convert to select * from employees where name = '?'" but what you need is select * from employees where name = ?". A '?' is the literal string ?, not a parameter to replace. We therefore have 3 modes that the SQL datasources (both Java and .NET) can be run.

1. sql.parameters=substitution – This is the way we have handled this to date and your templates will all work fine with this setting. This setting is not the default – you need to set it in your properties file.
2. sql.parameters=parameters – This will change your vars in the select to a parameter, unless the var starts with an _ like ${_var}. For ${_var} it will use substitution. This mixed mode is the default.
3. sql.parameters=parameters.always – This will change vars to parameters regardless of the name.

 

Windward will not set the default to a setting that breaks existing templates lightly. Windward has found that most new customers will continue to use the default setting and we think the mixed mode is better moving forward. This is the only way to bring about this change.

You can add this setting to your properties file now, before you upgrade to version 9. In version 8 the setting will be ignored as the version 8 engine has no idea what it means.

When timestamp sporadically work and how to resolve the signtool.exe issue

So after 2 days of scouring the internet searching everything from Google to Experts-Exchange, I have finally resolved my issue.

 

It all started when I was running our routing build scripts which contain code to automatically call signtool.exe to sign our DLL, EXE and MSI files.

 

Our calls look very similar to what you would see in the signtool documentation. We have purchased our code signing certification through GoDaddy but had another one through Verisign before hand

In our project file we setup our parameters up top:

<PropertyGroup>

<signtool>"..\tools\signtool.exe"</signtool>

<signoptions>sign /f ..\YOUR_KEY_FILE.pfx /p YOUR_PASSWORD /t http://tsa.starfieldtech.com</signoptions>

</PropertyGroup>

We would then make a call below as follows:

 

<target>

<Exec Command="$(signtool) $(signoptions) PATH\FILENAME.msi"/>

</target>

This resulted in the following output:

 

C:\src\Hekili\DotNetEngine>..\tools\signtool.exe sign /f ..\YOUR_KEY_FILE.pfx /p YOUR_PASSWORD /t http://www.starfieldtech.com PATH\FILE.exe

Done Adding Additional Store

SignTool Error: The specified timestamp server could not be reached.

SignTool Warning: Signing succeeded, but an error occurred while attempting to

timestamp: PATH\FILE.exe

Number of files successfully Signed: 1

Number of warnings: 1

 

Very weird in the fact that the EXE was properly signed when called from the command prompt but still gave errors.

 

Finally I decided to run WindowsUpdate and found that my Windows XP root certificates were out of date. This was causing a delay while trying to reach http://www.starfieldtech.com and it was just enough to cause signtool.exe to fail but also properly sign the EXE when response was finally received from the timestamp server.

 

Lesson learned: Always make sure your machine is up to date before digging into ambiguous network issues.

 

--TR

Installing Microsoft Office SharePoint Server 2007 (Moss) on Windows Server 2008 R2 not a smooth process

Ok, I typically think of myself as a fairly astute admin who can usually head off "gotchas" at the pass. However, time after time I run into ones that become a major time suck. Today's challenge was the simple task of installing MOSS on a newly created Hyp-V machine with a fresh install of Windward Server 2008 R2. R2 is great and it provides a lot of the UI enhancements that Windows 7 offers so that is why it is now the standard for any new servers I need to create.

Back to MOSS. The stock download ISO from MSDN should work, or at least that is what I thought. It turns out Server 2008 R2 is very picky about what it lets install on the system. The main problem is the bootstrapper launches and R2 will not let it proceed because the installer does not have access to the latest service packs and updates. The stock ISO from MSDN contains SP1 but this is not good enough to get past R2's requirements. You have to download WSS 3.0 and MOSS 2007 service packs and updates and then extract them over the installers "updates" directory to get things going. This basically slipstreams in SP2 to the SharePoint install. There is a link to the SharePoint Team's blog that walks you through this located HERE.

Everything looks pretty good from the SharePoint Team's blog entry excepted a few things I noticed.

• First if you have a fresh OS install you have to add the .NET 3.5 feature. Intuitive in hindsight but when you are trying to get and install done fast, easily overlooked.
• Second, you need to follow the extra steps and grab the special hotfixes they reference in the article and slipstream them in otherwise you will not get the bootstrapper to go forward.

How to slipstream SP2 for WSS 3.0 and MOSS 2007 into the original package.

1) Make sure you add the .NET 3.5 feature to your server before you start. This will install IIS as well

2) Mount the MSDN ISO image using an extraction program (I used WinRAR). Extract all files to a directory on your target machine you wish to install SharePoint.

3) Delete all files from the PATH_TO_EXTRACTED_MEDIA/x64/Updates folder. These are the stock updates included in the ISO and we are going to update these.

3) Follow the directions in the article below. Basically run each .EXE file in the /Updates folder and extract it using the /extract:PATH_TO_UPDATES_FOLDER /quiet command.

4) delete wsssetup.dll from the PATH_TO_EXTRACTED_MEDIA/x64/Updates folder

5) Then run the setup.exe file in the PATH_TO_EXTRACTED_MEDIA/x64 folder

6) The installer will complain that SQL Express does not have SP3 applied in the installer. Just ignore the error, continue and update it later when the installer is done.

http://blogs.msdn.com/sharepoint/archive/2009/10/02/install-sharepoint-server-2007-on-windows-server-2008-r2.aspx

 

A special thanks to the SharePoint Team Blog for getting me started on this but these few pieces of information will get you a complete install.

Also if you are in need a reporting solution that you want to drop into SharePoint checkout Windward Reports product called the Windward Arrow 3.0