Not sure how many of you have hit this, but recently we have had a problem with users not being able to print out reports from the browser. When they hit the print icon after runnig a report, they are given the message

‘Cannot load client print control’

Turns out that one of the patches Microsoft issue out (on a seemingly never ending basis) breaks(well, blocks) the activex. The patch in question is the ActiveX killbit one (i cant remember the kb number), there appears to be a problem with the old version of the print control activex, and when the latest patch is applied to the clients it stops the print control working.

The way to get it working again is basilcly to patch your reports server. This is something i am always a bit cautious of doing, as in the past i have had problems (service pack one removed the ability to do a multi select parameter) but this time i had a virtual server i could snapshot, patch then test.

To get it working again, i installed first of all SQL 2005 service pack 2 (http://www.microsoft.com/downloads/details.aspx?FamilyId=d07219b2-1e23-49c8-8f0c-63fa18f26d3a&displaylang=en), then the latest hotfix rollup (http://support.microsoft.com/kb/956854). On a couple of the client machines this seemed to fix the problem without having to re-download the control, but on others we had to remove the control first, then re-install it and it worked a treat

First off, i apologise for not blogging for a while, ive had quite a few other projects on over the summer, plus holidays so I’ve not really had time. Hopefully now I should be able to get back into it with a bit more frequency.

Anyway on to the topic of this post. Most applications nowadays will automaticly go onto the web and check to see if there is a new version, and if there is offer to download/install/visit page etc. I was looking for a simple way to do this using the dotnet framework and Visual Basic.Net, and came across the System.Net class.

This class is extremely powerful, as it contains functions for network communication.  The main one we will use here is the System.net.WebClient. We are going to use this to pull a file down of our web server that will give us information about the latest version of our application.

Information File

So first of all, create a text file, we are going to look on our web server for this file and read information. In the file we will have the following info: App name, version and download location, delimited by a pipe (|) character. You could also add extra things like new features, release date etc to this file. The example file will look something like this.

1.1.0|TestApp|www.beakersoft.co.uk/downloads/

Once you have this file, save it as something like TestApp_Ver_Control.txt, and upload it to your web server.

Downloading the Version information

Now the file containing version information is on your web server, we can write a function in vb that will open the file up, get the information contained in it and use that information to decided if our application is the latest version or not. This is where the System.net.WebClient comes in. First of declare a couple of variables. One is the WebClient, one is the url of the file you have just uploaded and a string array to hold the details of the file.

Dim myWebClient As New Net.WebClient
Dim RemoteUri As String = "www.beakersoft.co.uk/TestApp_Ver_Control.txt"
Dim strFileInfo()As String

Now, we can go and get the file of the web server, using the webclient and read the contents into a string. Then we can split the content of the string up using the pipe char, and there you have all the info you need to check the version.

All the code is wrapped up in a try/catch block to make sure we dont get any unhandled errors such as when there is no net connection, file missing etc.

	Try
	Dim file As New System.IO.StreamReader( _
                    myWebClient.OpenRead(RemoteUri))
        Dim Contents As String = file.ReadToEnd()

	'Split up the sections of the text based on the pipe (|) delimiator
	strFileInfo = Split(Contents, "|")

	'see if we need a new version
	If strFileInfo(0) > Application.ProductVersion Then
		'if we have a new version, make sure the app name matchs from the file
                If strFileInfo(1) = application.ProductName Then

			'we have a new version! So throw up a message, set a flag ect

                End If
	End If

	'close the file stream and web client
	myWebClient = Nothing
	file.Close()

        Catch ex As Exception
	If InStr(ex.Message, "(404)") Then
		'404 means file not found on webserver
                Msgbox("Problem Finding the update information file - " & vbNewLine & ex.Message & _
                        vbNewLine & "Please contact the appliaction vendor")
	Else
                Msgbox("Problem getting update information - " & vbNewLine & ex.Message & _
                        vbNewLine & "Check your internet settings and try again")
	End If
End Try

And thats pritty much it! This is a very bare bones way of doing it, and you probably want to add in support for using a proxy (you can do that using the System.Net.WebRequest.DefaultWebProxy class, and pass login credentials to myWebClient.Credentials using Net.NetworkCredential ) but as a very basic form this should work.

Hot on the heals of the last version, Spiceworks 3 has been released. You can see a list of the new features at http://spiceworks.com/3.0/ and download it at www.spiceworks.com

Here’s a list of some of the new features that interested me

• The interface has been cleaned up quite a bit from the previous version. There are also a couple of new features such as the ‘Glide’ function, it’s kind of like the iPod artwork browser.
• The network scanning has speed has been improved (see my test results below)
• The detection of devices has been improved.
• Exchange server monitoring. (i think this is particularity cool)
• Whole Environment event charts
• Loads of bug fixes

I am in the process of writing a reporting service that will be used across our whole company. The problem I have is there is not one central database all the reports will run of, each division has its own separate one. Lucky the database schema’s are consistent, but I needed a way of:

a) setting the report data source at run time and
b) letting the users control the database they want to connect to. Some high level user need to be able to access multiple databases, while others will just need access to their local one

So, here’s how I went about doing it.

Setting Data source at Run time

Normally, when you setup a reports data source in reporting services, you just point it to the database you want it to use (probably using a shared data source) give it some credentials and off you go. You would probably end up with a connection string looking something like this:

Under normal circumstances that would work fine. But not this time. I need an easy way to replace the information held in the connection string with some sort of variable.

Turns out the easiest way to do it is by using a parameter in the connection string. You can create the connection string as an expression as if you were working with any other part of the report. However, before doing this you first need to create the parameters and fill them with some data.

Data Source Table

In the reports database, I created two new tables, one that will hold the name of the reports servers, database names and Active directory group with access to this data source. The other one will contain all the user names and what Database they are currently using. Download the SQL scrip to create the databases below

hello

Run this script on your reports sever database, and you will have two new tables, database_details and user_details. In order to do the tests you will need to create an entry in the database table (database_details) for your database, and an entry in the user table (user_details) for your username (include the domain name so it should read dom\joe.bloggs) and point it using the site_id filed to the database. You are now ready to create the SQL in the report that will populate the parameters

Dataset Containing the database connection details

Create yourself a test report, and in that report create a new dataset that points at your reports server database. The SQL needs to be the following:

SELECT     jp_user_details.username, jp_database_details.server_name, jp_database_details.database_name
FROM         jp_user_details INNER JOIN
jp_database_details ON jp_user_details.site_id = jp_database_details.site_id

This will return all the names in your database, what we need to do now is make sure at run time it only returns data for the user running the report. To do that we need to put a filter on the report. The filter will be:

Fields!username.value=User!UserID

and should look like this in your Dataset properties

The Parameters

Once you have done this dataset, you need to create a couple of parameters. One will be for the server name, one for the database name. So go into your report parameters and create the following, with these options:

Name – ServerName
Datatype - String
Hidden - Yes
Available Values from Query: Select your dataset , then both values fields need to be server_name
Default Values From Query – Select your dataset, value field is server_name

Name – DatabaseName
Datatype - String
Hidden - Yes
Available Values from Query: Select your dataset , then both values fields need to be database_name
Default Values From Query – Select your dataset, value field is database_name

What does this do? Well, when you run your report now you will have the two parameters you have just created filled in with the server name and database name the person running the report wants to report on. The parameters are set to hidden so the user knows nothing about them.

Final Step, create your dynamic dataset

Now we have everything we need in place, the last step is to create a dataset that will look into the server held agaist the user, and retrive us the actul information we want. Create a new dataset, and in the connection string of this data source put the following:

= “data source=” & Parameters!ServerName.Value & “;initial catalog=” &  Parameters!DatabaseName.Value

It should look like this in the window

Now when you run the report, you data source will be based on the users choice held in the table

A couple of things to note

You will find it hard (probably impossable) to write the report with the parameterized data source. You’ll need to work with your local copy of the database hardcodded into the connection string first, then when you are happy with it change it to the parameter driven one. If you dont do this the report designer wont be able to read the dataset.

You also need to be carful the order in witch you put your user paramters on the report. I found that if i did’nt put data driven parameters (ie a list of sales areas the user can select) at the top of the list, they were greyed out when you tried to run the report. Not sure why, but i asume its down the the order the datasets are exceuted in

If you have any problems with this, or have any different ways of doing it let me know!