Business Intelligence "lights up" with Office SharePoint 2007 was the topic.
Sydney SQL Server User Group meeting on Tuesday 1st August 2006
This must have been their most packed session to date!
Possibly 100 people there and the lecturette was packed!
There was no pizza this time, instead they had sub-way or some similar type of rolls
– These weren’t too bad but how long will the healthy food keep coming?
One event coming up is SQL Code camp October 7th and 8th in Wagga Wagga at the Charles Sturt Uni.
This is funded by Microsoft but accommodation and food is up to you.
http://www.sqldownunder.com/CodeCamp/tabid/53/Default.aspx
Grant stepped us through using Excel 2007 and how it works nicely with Excel services.
Microsoft appears to be gearing Excel 2007 as the new tool to extract and view your database/cube information.
And it has a lot more smarts built in than the earlier versions of excel with the cube add-ons etc.
Also the new SharePoint ties in all your business intelligence a lot better and easier than ever before!
There is going to be a major stampede when this product is released for this aspect alone.
I liked the one point grant raised but Business intelligence – You can make good decisions, wrong decisions and bad decisions, but what is the difference between a wrong decision and a bad decision? The answer was a bad decision is made when you haven’t got enough information!
The main point here is that some organisations may have a few people running office 2007 just so they can publish the “server based” excel workbooks etc.
Others can read and input parameters to generate different results via a web browser interface.
So this might be a great way to publish excel like reports with charts and other interactive features to key groups of users!
The KPI options in SharePoint lists look cool and will probably be demonstrated over and over again.
There was also the bars inside a columns with different colours based on the values using some standard deviation formula to show more reddish the lower end and more greenish the upper end.
One trick with Analysis services is not to include fields that you won’t need. It is too easy to select everything from all your tables etc.
Fields like phone numbers and names are probably only important when you drill down, and these should be excluded from the cubes and be shown on drill through via a SQL query rather than via the cube.
Another nice to have feature was the ability to drill down in the same column. Means the columns to the right with the key values don’t get pushed off your screen to the right.
The standard dashboard template was great and was shown linking to an excel services file as it was difficult to find and set the right permissions to analysis services etc.
The new SharePoint Server and SQL Server 2005 each have a very tight security to deploy and will require knowledgeable people to configure anything and everything as access is turned off for just about everything.
Regards,
Tom Bizannes (B.Business,MCP)
Microsoft Certified Professional
(Microsoft SQL Server Database Administration and Design)
MacroView Business Technology
http://www.macroview.com.au
Microsoft Gold Certified Partner
Phone: 61 2 9249 2700 Fax: 61 2 9279 4111
"Solutions in SharePoint and Office"
2005 Winner - MSD2D Readers Choice award - Document Management
Wednesday, August 02, 2006
Sunday, May 07, 2006
Microsoft SQL Server User Group Sydney
Tuesday 2nd May 2006
Well the pizza was hot and there was plenty of it.
Dr Greg Low presented and his depth of knowledge is very good.
There were no new announcements except to say to look out for SQL down under podcasts.
http://www.sqldownunder.com/
They mentioned fun with installing sp1 for sql server 2005. One trick was to stop the services only at a particular point. Will need to try it to see how easy/difficult it is....
Again we here another reason to upgrade to SQL Server 2005. This time it was because stored procedures will run faster as they do statement level execution rather than recompling the whole batch.
This means, less memory is used, faster execution and less compile locks.
This also means you don;t need to break stored procedures up into small ones to run faster, as has been the "workaround" in SQL Server 2000...
There were a few interesting articles to look at regarding this, if you want to write better stored procedures. Names of these authors were Arun Marathe and Tibor Karaszi so will need to Google these guys for their SQL articles.
Some tricks we were advised about were:
keeping naming identical even case sensitivity is important as well and spaces etc.
Strong naming was also raised as a good way to call your stored procedures, saving it looking in the master, then for the current user and then for dbo. Also don't start stored procedures with SP_.
e.g. exec proc1 will look for username.proc1 and then dbo.proc1
and sp_proc1 will look for sp_proc1 in the master database before looking for username.proc1 and then dbo.proc1. So the more you qualify the name the better.
Then we had a general session and talked about various things:
One tip is to use checkdb shrinkfile rather shrinkdb for your sql server 2000 databases etc.
Pro-clarity was bought by microsoft and they have a BI client and also work in excel? Will need to investigate further.
http://www.proclarity.com/
Mendocino will be called duet and this is a SAP connector tool...
http://www.eweek.com/article2/0,1895,1956671,00.asp
Tom Bizannes
Microsoft Certified Professional
http://www.macroview.com.au
Well the pizza was hot and there was plenty of it.
Dr Greg Low presented and his depth of knowledge is very good.
There were no new announcements except to say to look out for SQL down under podcasts.
http://www.sqldownunder.com/
They mentioned fun with installing sp1 for sql server 2005. One trick was to stop the services only at a particular point. Will need to try it to see how easy/difficult it is....
Again we here another reason to upgrade to SQL Server 2005. This time it was because stored procedures will run faster as they do statement level execution rather than recompling the whole batch.
This means, less memory is used, faster execution and less compile locks.
This also means you don;t need to break stored procedures up into small ones to run faster, as has been the "workaround" in SQL Server 2000...
There were a few interesting articles to look at regarding this, if you want to write better stored procedures. Names of these authors were Arun Marathe and Tibor Karaszi so will need to Google these guys for their SQL articles.
Some tricks we were advised about were:
keeping naming identical even case sensitivity is important as well and spaces etc.
Strong naming was also raised as a good way to call your stored procedures, saving it looking in the master, then for the current user and then for dbo. Also don't start stored procedures with SP_.
e.g. exec proc1 will look for username.proc1 and then dbo.proc1
and sp_proc1 will look for sp_proc1 in the master database before looking for username.proc1 and then dbo.proc1. So the more you qualify the name the better.
Then we had a general session and talked about various things:
One tip is to use checkdb shrinkfile rather shrinkdb for your sql server 2000 databases etc.
Pro-clarity was bought by microsoft and they have a BI client and also work in excel? Will need to investigate further.
http://www.proclarity.com/
Mendocino will be called duet and this is a SAP connector tool...
http://www.eweek.com/article2/0,1895,1956671,00.asp
Tom Bizannes
Microsoft Certified Professional
http://www.macroview.com.au
Subscribe to:
Posts (Atom)