The Power of Data View Web Parts
I recently had an opportunity to mirror some Access reports in SharePoint. It reminded me how powerful Data View Web Parts in SharePoint really are. Here’s what I did…
The Access front end was using SQL Server as its back end data server, so I knew that I could get at the data from SharePoint. The first step was to create a blank site in SharePoint. Then, in Frontpage (I used Frontpage because this was a SharePoint 2003 site — better safe than sorry), I went To Data/Insert Data View. Under Database Connections, I created a connection to the SQL Server database and specified that I would use a custom query. I dropped the SQL query from Access into the custom query dialog, closed the window, took a look at the Data View and whoops — it didn’t work. I kept getting the error below every time I tried to look at the Data View.
It turns out that I was getting caught by the friendliness of Access. Access is fairly forgiving about query syntax, where SQL Server is not. So, for instance, when I did a tablename.field = No in a WHERE clause, SQL Server didn’t like it. It turns out that it wanted me to say tablename.field = 0, because that is the actual value stored in the field. There were a few other little peculiarities like this, but after some fiddling, I was able to get the query to run.
Once it was running, I inserted the Data View into the site. When you do this, you get a very basic table containing the results of you query. Not pretty, but the data is there. However, there is virtually total freedom in formatting the table. Since I was mimicking an Access report, I wanted the Data View to look just like the printed report. After about 30 minutes of fiddling with grouping, sorting, and formatting, I was able to go from this:
to this:
and with full control of the formatting (and had the client wanted it), it could have looked even nicer!