July 4, 2014 at 3:18 am
All of this is all well and good until you try to use it like:
...it is such hard work.
The custom authentication is a massive headache. There are not many resources online about the configuration required. There is no UI whatsoever to do this you have to do it all by hand changing XML files where one wrong character can screw you over.
MS has depreciated report models in SSRS 2012 so pretty screwed if you are using them once 2008 R2 is dropped from MS support.
Creating a simple report that shows a master line, several details rows, master line, several details rows which takes 5 minutes in something like MS Access after writing the query is only possible with a sub report that has it's own dataset in SSRS - i.e. a lot more work - at least using report builder - which given the context of a self-surface web app is the only option.
Think very carefully about your requirements before integrating this into your product. I for one would love to rip it out and not use it - we only used it because we were using SQL Server for the data storage so we already had it - hindsight, sweet hindsight - if only I could have seen the future.
July 4, 2014 at 1:48 pm
This looks promising. Looking forward for more.
What are your plans ?
Visual Studio 2008 or the SSRS report builder ?
Will you use SQL Server datasets or use FetchXML ? FetchXML did not impress me too much last year when I found out it could not support what I could do easily in T-SQL:
SELECT AccountIdName, SUM(TotalAmount_Base) AS AccountTotal FROM Invoice GROUP BY AccoountIdName
A thing to note: caution is required using T-SQL and directly refering to tables instead of views. In its wisdom, for CRM 2013, MS dumped the idea of creating ...ExtensionBase tables when new fields are created with the CRM environment. All custom fields are now added to the ...Base tables. Which means migrating my T-SQL-based reports from CRM 2011 to CRM 2013 I will have to rewrite my T-SQL so stop looking for ...ExtensionBase tables.
I did not like too much using the Views automatically constructed by the CRM environment, each view returning typically 100 columns when I select only a half-dozen. Not familiar enough with the inner workings of SQL Server to determine whether or not the remaining 94 columns still end-up as dead weight overhead even if not selected.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply