Recently in SQL Server Category

SQL Server Magazine in conjunction with Windows IT Pro just published my article on Report Builder 2.0 security issues. Actually, the content is extracted from a much larger article on Report Builder that’s scheduled to be published in the print magazine later this year. The gist? Well, basically it discusses the implication of giving paradevelopers on your staff the ability to party down on your report catalog. These folks will be able to extract cataloged reports, modify them and save them back for everyone to see—whether or not they still represent an accurate depiction of your corporate data…

A third-party report generator (Pebble Reports) sent me this IBM presentation (see page 71) when I asked if their tool supported 2005, 2008 or 2010 RDL (they only support 2005).

“We depend on ReportViewer control for printing purposes and we are as miffed as you are that ReportViewer is always out of sync with ReportServer. Even MS competitors are taking advantage of this situation, for example see slide 71 of this IBM presentation where they talk about Microsoft's version incompatibilities.”

This further adds to the argument that Microsoft is not seen as capable of keeping their various development paradigms and the metadata they support in sync. I pounded on this issue two years ago when Visual Studio 2008 was getting ready to ship. However,  two years later Visual Studio BI and ReportViewer developers are facing the same lack of compatibility with the latest RDL (about to ship with SQL Server 2008 R2). Are developers expected to wait another two years before the ReportViewer control will work with RDL 2010 in local mode? By then I expect additional innovations to be out of reach as RDL evolves—leaving the ReportViewer control perpetually one version behind.

I’m well into the research for my new (and overdue) SQL Server Magazine article on Report Builder 2.0. Along the way I’ve discovered a couple of interesting bugs. It seems that if you choose to use the “Stored Procedure” command type you can indeed name a stored procedure, but the wizard won’t set it up correctly unless it has defaults defined for each of its parameters.

Incidentally, you had better be prepared for the wizard to execute this puppy (not just parse for signature) as the SP gets executed at least once if not several times in the process. I expect this would be a problem if the SP took seven and a half hours to execute…

I also discovered that even when defaults are defined, the wizards don’t properly map the query parameters the first time. Once the Dataset is created you have to go back to the DataSet properties and Refresh Fields. Tacky…

I’m still tracking down why stored procedures are not listed along with the Tables and Views in the Query editor… I expect it might be (another) Windows 7 rights issue.

hth

Progressive Business and Beta V have partnered together to present another series of technical webinars. The current series focuses on SQL Server and Reporting Services and consists of six 90-minute talks given two a day for three days. The next scheduled offerings are September 9-11, October 13-15 and November 2-5th. See the following link for an outline and pricing details. Note that this series includes a copy of Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition) as well as a copy of Hitchhiker’s Guide to SQL Server 2000 Reporting Services—once we get them from the publisher…

Visual Studio, SQL Server & Reporting Services: 6 High Impact Training Sessions
This is a set of 6 seminars given in two parts—one that focuses on SQL Server, the second on Reporting Services. This high-impact series of training webinars is for anyone who wants to leverage Visual Studio, SQL Server and Reporting Services best practices—learning what works, what doesn't and why. These sessions are for developers, architects and managers who want to know how and (more importantly) when to leverage the power and benefits of SQL Server and Reporting Services.

Another day lost. As many times as I’ve helped others get connected, nothing worked today as I tried to connect from one system in a Workgroup to a SQL Server on a local (trusted) domain. I tried everything imaginable including:

• Checking to see it the server properties were set to permit remote connections. They were.
• Was the SQL Browser service running? It was.
• Did the SQL Server Configuration Manager say that the right protocols were enabled? Yes, they were.
• I tried to Telnet to the IP address and port being used (based on SSCM). It worked locally but not over the network.
• I stopped the Windows Firewall service as I was running Small Business Service and it thinks it knows best about configuring client firewalls (despite the fact that I have other firewall hardware). That made no difference.

Nothing made any difference. I could not connect from other domain-based systems either. The rest of the story? Well, I remembered having installed Windows 7 on top of an existing Windows Vista system. I had assumed that it had joined the SBS domain correctly (I ran “Connect” which was supposed to do that). Apparently it didn’t. When I dropped the offending system from the domain, went into SBS, dropped the system there, and rejoined the domain it worked fine. Everyone could see the SQL Server. That only took 6 hours of fiddling to figure out. I’m hesitant to run connect again…

Sigh. How does anyone get any work done if all we do is frutz with systems?

Bill

Progressive Business and Beta V have partnered together to present another series of developer-centric webinars. The current series focuses on SQL Server and Reporting Services and consists of six 90-minute talks given two a day for three days. The next scheduled offerings are September 9-11, October 13-15 and November 2-5th. See the following link for an outline and pricing details. Note that this series includes a copy of Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition) as well as a copy of Hitchhiker’s Guide to SQL Server 2000 Reporting Services.

Visual Studio, SQL Server & Reporting Services: 6 High Impact Training Sessions
This is a set of 6 seminars given in two parts one that focuses on SQL Server, the second on Reporting Services. This high-impact series of training webinars is for anyone who wants to leverage Visual Studio, SQL Server and Reporting Services best practices- learning what works, what doesn't and why. These sessions are for developers, architects and managers who want to know how and (more importantly) when to leverage the power and benefits of SQL Server and Reporting Services.

The webinars I’ve already recorded (and those I’m going to present) can be found by visiting this site. Look under the “IT” heading to see links to the content. The recorded sessions might be repeated in the future but the recording are available:

CLR Executables: Stored Procedures, Functions, Aggregates, & User-Defined Types
(presented May 13, 2009)

• This session will discuss how to create CLR executables in Visual Basic.NET and C#. We'll see how to create CLR stored procedures, functions, aggregates as well as user-defined types. The session demonstrates CLR executable development through use of Visual Studio as well as SQL Server Management Studio.

Hitchhiker's Guide to Visual Studio & SQL Server Reporting 

(presented April 7, 2009)

• This session discusses how Visual Studio developers can leverage the power of the Report Definition Language to manage and generate client-side reports or launch SQL Server Reporting Services reports. We'll discuss the latest MicrosoftReportViewer control as well as the Business Intelligence toolset exposed in Visual Studio 2008.

Managing and Writing High-Performance SQL Server Stored Procedures
(presented March 12, 2009)

• Stored procedures have been recognized by database administrators and developers as the most efficient mechanism to access and protect SQL Server databases. When written and executed correctly, these server-side blocks of code can significantly improve performance, security and developer efficiency.

IMHO, I think that SQL Server Developer Edition should have a “switch” to permit developers (ideally on a connection-by-connection basis) to “select” which version of SQL Server is being executed. As most of you know the difference between the versions is all done with mirrors as the bits are the same for the most part. I can’t see that it would be that hard to expose that selection switch so a developer could test his application and the server-side executables on the version of SQL Server he or she is targeting.