I'm wondering if anyone is currently utilizing Microsoft's Master Data Services? How you are utilizing it? Whether you find it useful? When you believe it would be useful? Thanks!
I have been working with MDS since it was first released as part of a feature pack for SQL Server 2008 R2. While MDS has some compelling features - most notably detailed data lineage, I am not confident in recommending it to clients yet.
My reason for this hesitation is the nature of the install and the tendendency to fail on upgrade or system change. I struggled mightily with the both the SQL Server 2012 RC0 MDS and the RTM installs. There are simply too many brittle aspects of the install (such as the hard requirement that the service be installed on a domain-joined machine and the need to install the Silverlight 5.0 SDK for the client to work properly). I also experienced flakiness in the the Excel add-in.
I see where Microsoft is going and I think the product will eventually be useful. Considering it's purpose (master data repository), MDS must be more 'rock solid' before I would use it in production.
We aren't using it currently in our office, however the presentation Microsoft did in town a while back seemed very interesting. I saw it as sort of a competitor to Oracle's OBAW warehouse. You've probably already looked at these, but Microsoft has a decent set of webcasts that cover how to install and use MDS out here:
http://www.msdev.com/Directory/SeriesDescription.aspx?CourseId=155
I'm anxious to see if anyone else is using it as well, we tend to have a hard time talking our management into letting us try these types of services without being able to point to other corporations that have successfully implemented said product.
We're just starting to investigate the use of MDS to support our consulting practice, specifically around data analytics and ETLs to deduplicate, standardize, and sanitize client data. It's probably just scratching the surface of MDS, but we were led to MDS initially for its inclusion of regular expression capabilities in SQL to transform free-form text data.
Before MDS/DQS, part of the sustainability / enduring-success of a custom database application was heavily dependent on one or both of the following items...
Having a full-time technical resource to manually update the master data. Someone who can work with the Business Experts and make the necessary adjustments to the data in the database.
Developing (in addition to the database/application/etc) a custom UI that is intuitive enough for the less-technical Business Experts to use for managing the master data themselves.
Neither of these were ideal from a cost-perspective. With MDS/DQS, a developer/contractor can come in, design an end-to-end Data Warehouse/BI solution including full integration with DQS/MDS (probably via SSIS packages) with relative ease. The Business-Experts can be trained to manage the master data using a UI they are already very familiar with (ex. Excel), and the developer/contractor can move on to the next project/client.
Also, if the business already has other data sources (via acquisitions or silo'd-yet-overlapping efforts or whatever), MDS can be used to manage all the master data in one centralized location.
It might not be the best MDS product available yet however it does come with SQL Server. Compared to most of the bespoke efforts for accommodating meta-data or master data in warehouse loads it's a pretty good option since most of the time is spent concentrating on the warehouse and the mastering of ancillary or other data isn't normally well accommodated for leaving questionable results. I prefer to use it than create some other flaky option that the customers will find it difficult to maintain. If you have budget however I would consider looking around for something more polished.
Like anything though give master data the respect it deserves. If it is going to be used then it's worth spending the time to model the entities, flow of data and usage correctly. The data stewards will need to savvy and will require training (it's not the most usable interface in the world - to say the least).
As we are a small consulting and development company we don't use MDS internally but we do implement it at customers with a focus on managing the Golden Record as the customers have a myriad of databases and applications all using the same data (customer, product …)
I agree with Lynn Langit's comment about installation and SilverLight dependency and the general comments about the UI. There are also a lot of smaller companies that don't run SQL Enterprise Edition but whom could benefit from MDS.
Those are the reasons why we are now developing a modern web application which we will host for our customers (probably on Azure).
If you're thinking about MDS I'd recommend to have a look at the API to replace (parts) of the UI.
Master Data Service is very useful for managing Master Data,
We have used Master Data Services 2012 and 2016, there are not too many features present in 2012 ,2016 is much better than 2012 with some new features , but I think still Microsoft needs to improve Master Data Services, they should include some flexibility in business rule's area.
Related
For my small company I am trying to build a data input form for several departments that input data into SQL tables. I would like to give the user the ability to input data, update existing data, and see graphs of historical data that they have inputted.
I personally know VB.net but my IT head wants to use PowerApp. No one knows PowerApp in the company but he thinks it will be easier to use and implement/share across the company.
Is PowerApp easy to learn?
Can Power App input data into MS SQL?
In general, which is better for my intended use?
Thank you!
YMMV, but in general PowerApps is easier than a programming-language based platform for building apps. It won't be as powerful as the latter, but for the specific example that you mentioned (data input, presentation), it should be fine. Take a look at the documentation, especially in the section about creating an app automatically from your data (the link talks about apps from SharePoint, but the same works for SQL Server as well)
Yes, data integration is built in the platform, and SQL Server (both SQL Azure and on-premises installations of SQL Server) is supported
As always, it depends (which is why this question may be closed for being primarily opinion-based). A full-fledged programming language will always have more power than a "no-code/low-code" solution such as PowerApps, but if what you need to do is within the domain of that solution, it will likely be easier to implement. PowerApps also makes it easier to deploy the app in mobile devices (iOS / Android), which is not as easy to do with VB.NET, but again, that depends on your scenario.
I don't have a specific question here but I'm more looking for some guidance regarding a new software project I'm starting at work.
Here is a description of the project:
I am refactoring windows software that was written in Visual Basic 6 and uses MS SQL Server for a database. The code is tightly coupled with SQL queries and references old active X controls.
The software can run in a standalone mode where its only running one instance on one computer or in a distributed mode where it runs on several machines simultaneously all connected to a shared data source.
The users of the software need use of a wide range of USB devices that are integrated with the software on the client side. (I'm assuming this means the new version of the software needs to be a desktop application and can not be a browser based web application.)
The new version of the software is going to be updated to use new technologies in an effort to modernize the code and improve performance.
I would like the architecture of the new software be both logical 3-tiers and to use design patterns if appropriate. Although I am new to design patterns it seem like there is an opportunity to use the abstract factory, observer, and singleton patterns together in the new version of the software.
In a very generic explanation the software has an "employee" database table that stores information about employees. The client side has a grid view that allows the user to view the employee information stored in the database and to make modifications to the data through the grid view. Data can be added to the employee database by the client using forms that have text fields and drop down menus. Employee related data can also be captured by USB devices on the client side and then that data can be added to the employee database as well.
In terms of how this relates to architecture I'm guessing there could be an observable singleton employee object that is observed by data display objects like a grid view object and that these data display objects are created by an abstract factory method. (Does that make sense?)
The new software will be written in Visual Basic using Visual Studio 2010. Aside from that none of the other technologies have been decided upon.
I think we will use windows forms opposed to the windows presentation foundation although I'm not sure as there might be some image handling functionality that we want that is better done with WPF.
From what I've read I like the Entity Framework and Linq but I'm not sure how that works in conjunction with the business logic layer with the design patterns I mentioned above.
Also, I'm trying to understand if we could use the windows communication foundation and web services. This makes sense when the software is running in distributed mode but not much sense in the standalone single machine deployment. Adding web services and using IIS might be overkill for what we are trying to accomplish. I don't know.
So this is what I'm working on and what I've been reading about and researching. I would greatly appreciate your thoughts on this and any guidance you can provide.
Thanks!
Aside from the fact that you will learn a lot during the development process I can give you the following recommendations:
Use Stored Procedures in the database for database access. This will prevent concurrency problems and also allows for transactions. This means if something goes wrong (users computer crashes etc) then no data nor data integrity is lost
Treat the windows forms as simply 'interfaces' between the user and the database. Hence they shouldn't contain anything that keeps track of data (let the database do that) and they're only a means of gathering and showing data
I had a very similar experience.
I tried importing a VB6 database project that ran as a standalone app into VB 2005, and the code was very ugly.
One book that I found very helpful with doing three-tier DB applications using VB.NET (VB 2005, actually) was ADO.NET 2.0 with VB 2005 published by Murach. Got me up to speed very quickly, and it gave direct examples of writing three-tier DB applications (business layer, presentation layer, and DB access layer).
Can't remember for sure if there's a newer version of the book, but I was impressed with the layout of that one. It also deals with web apps.
Beyond that, I did some code generation to streamline hacking out the Object classes and the DB access classes for my project.
I believe this project is really going to have you learn and gain a lot of experience.
Like eddy556 said, use the forms only as interfaces. It works better that way.
Plus, if you have any problems, don't hesitate to ask. That's what we the StackOveflow team are here for anyway.
Good Luck.
I manage a small team of developers who up till recently have all been working on independent projects.
We have now all come together to work on one holistic project and its really tough. People are changing things, without consulting other programmers and its very difficult to manage.
We are also working in a pure production environment (no test/production)
I am a bit lost on where to start, I am looking at products like Team Foundation Server or their is a product by Red gate called "Source control"
Does anyone know any good books on the above subject, I cannot be the only person in this situation? :)
Source Code:
If you're looking for how to use source control (versus how to get your team to a controlled source environment) you should check out Source Control HOWTO by Eric Sink. The disclaimer here is that he has written a source control product but the HOWTO isn't specifically tailored to it.
Database Schema:
If you're looking for how to get your database (structure not data) in source control (since it was mentioned in the title) then you should check out this Coding Horror post: Get your database under version control. It covers some basic concepts and points to a few articles on how to actually implement getting your database in source control.
Source Control Software:
If you are looking for actual source control software, a list of applications can be found here: List of Source Control Systems with Visual Studio Plugins.
Don't make the mistake I did when putting the database definition under source code control by allowing branches and merges. This led developers (and managers) to assume they could have several versions of a table in the same database, leading to programmers overwriting each others changes, and having incompatible versions of source code and table definition all over the place.
As you might well imagine this lead to a great deal of wasted time and many frayed tempers.
Depending if time or money is more important, do you have the option to being someone in for a short time with the specific task of improving your processes? They would be able to set you up a test environment, install a version-control server and get your guys (and you) up to speed.
The first thing that you need to do is to give every developer their own copy of the database.
Secondly, you need each dev to be able re-create a baseline database from the master.
Once each dev is happy with their changes to the database, you will then need them to create a series of patches for their changes.
Lastly, each one of these patches needs to be able to checked in to source-control, and re-distributed to the other devs.
If you are looking for a good source control server, consider Subversion, with Tortoise SVN as your client.
Take a look at DBSourceTools. (http://dbsourcetools.codeplex.com).
It's specifically designed to help developers use source control for database changes.
This tool will allow you to baseline your database at a specific point, and create a named version (v1).
All files are scripted to disk, and very easy to add to a Subversion repository.
Have a look at the patching process for creating and using patches.
Have fun.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Okay, I will shortly be starting down the path of windows mobile development. I know nothing about the subject really and I am looking for people with experience to let me know of any gottchas you may know of.
Right now I dont even have a breif of what is requied but the assumption is that the application will be very little more than a bunch of CRUD forms for updating data. The only other requirment knowladge I have is that the application will need to support offline storage when there is no signal avaliable. This in turn will obviously require some kind of syncronization when signal returns.
My initial thoughts are that the application will primarily be a front end to interact with a web service layer. Im assuming that WCF will be an appropriate technology for building these services? I also thought that SQL Server CE would be a good route to go down with regards to the offline storage issues.
Any knowlage that you feel is useful within this domain would be appreciated. Advice, links, books anything appreciated.
EDIT: It has been noted that there are two ways to go with off-line synchronization. To either use some form of message queuing or to use SQL synchronization tools. Could anyone offer a good comparison and introduction to these?
EDIT 2: After a little more digging I get the impression that there are basically 3 different approaches I can use here:
Emmbeded Database to query against then syncronization online, when able
MSMQ along with .NET remoting
WCF with ExchangeWebServiceMailTransport bindings using Exchange Server.
Now, there has been a nice few points raised on the first issue, and I think I understand at some level the issues I would face. But I'd like to get a little more information regarding MSMQ implementations and using WCFs new bindings.
Here a few words from my experience so far (about 9 months) of .net Windows Mobile development.
Well you are occasionally connected. (Or more likely occasionally disconnected). You have to choose whether you are going to use messaging with queues (i.e. WCF/SOAP/XML or something like it) or database synchronisation. I choose the SQL synchronisation route so I can't really comment on messaging. The SQL synchronisation route is not hassle free!
If you go down the sync route with SQL compact like me you basically have two choices. SQL Server merge replication or the newer ADO.NET Synchronisation services. If you choose the former you need to be really careful with your DB design to ensure it can be easily partitioned between mobile subscribers and the publisher. You really need to think about conflicts, and splitting tables that wouldn't normally be split in a normalised DB design is one way of doing that. You have to consider situations where a device goes offline for some time and the publisher DB (i.e. main DB) and/or a subscriber alters the same data. What happens when the device comes back online? It might mean resolving conflicts even if you have partitioned things well. This is where I got burnt. But SQL Merge Replication can work well and reduces the amount of code you have to write.
Roll your own DAL. Don't attempt to use datareaders etc. directly from UI code and don't use typed datasets either. There may be third party DALs that work with Windows Mobile (i.e. I know LLBLGEN does, might be worth a look) but Linq-to-SQL is not supported and anyway you need something lightweight. The chances are the DAL won't be too big so roll it yourself.
If you are using .net you'll probably end up wanting some unimplemented platform features. I recommend using this inexpensive framework to give you what your missing (especially as related to connectivity and power management) - http://www.opennetcf.com/Products/SmartDeviceFramework/tabid/65/Default.aspx
Windows Mobile devices partially switch off to save power when not in use. If you are doing a polling type design you'll need to wake them up every x mins. A normal .net timer class won't do this. You'll need to use a platform feature which can be used from OpenNetCF (above). The timer class is called LargeIntervalTimer and is in the OpenNetCF.WindowsCE assembly/namespace (I think).
Good Luck!
SqlCE is only one of the options available for local data storage on a Windows Mobile device, and although it's an excellent database it has limitations. For one thing, SqlCE will not work (period) under encryption (in other words, if your user encrypts the location where your SDF file is, you will no longer be able to access the data).
The second (and most critical) weakness of SqlCE lies in the RDA/Merge Replication tools. SqlCE Merge Replication is not 100% reliable in situations where the network connection can drop during replication (obviously very common in Windows Mobile devices). If you enjoy trying to explain missing or corrupted data to your clients, go ahead and use SqlCE and merge replication.
Oracle Lite is a good alternative to SqlCE, although it too doesn't work properly under encryption. If encryption is a potential problem, you need to find a database engine that works under encryption (I don't know of one) or else write your own persistence component using XML or something.
Writing a WM application as a front end that primarily interacts with a web service in real time will only work in an always-connected environment. A better approach is to write your application as a front end that primarily interacts with local data (SqlCE, Oracle Lite, XML or whatever), and then create a separate Synchronization component that handles pushing and pulling data.
Again, SqlCE merge replication does this pushing and pulling beautifully and elegantly - it just doesn't work all the time. If you want a replication mechanism that works reliably, you'll have to write your own. Oracle Lite has something called a snapshot table that works very well for this purpose. A snapshot table in Olite tracks changes (like adds, updates and deletes) and allows you to query the changes separately and update the central database (through a web service) to match.
This thread I just posted on SO a few days ago has proven to be a great resource for me thus far.
Also the Windows Mobile MSDN WebCasts are a wealth of information on everything from just getting started up to advanced development.
I would suggest Sqlite for local storage. From the last benchmark I ran it was much better than SqlCe and you don't have to do stupid things like retain an open connection for performance improvements.
Trade-offs being that the toolset is less rich and the integration with other MSSql products is nil. :(
you might want to refer to this:
getting-started-with-windows-mobile-development
You shouldn't be intimidated for windows mobile development. It isn't much different from desktop development. I strongly recommend that you use .NET Compact Framework for development and not C++/MFC.
Some useful links:
Mobile section at the Code
Project. You would find a lot of
articles, a little digging is needed
to find the appropriate one.
Smart
Device Framework from OpenNetCF
offer valuable extensions to the
compact framework.
When you install
the Mobile SDK, you will find under the
Community folder links for the
Windows Mobile and CF framework
blogs. These are also valuable
resources.
Regarding your application, you are right about the WCF and the SQL Server CE. These are the proper ways for handling communication and storage.
Some hints for people coming from a desktop world:
You need to have some sort of power management. The device may automatically go to suspend state. Also, you shouldn't consume power when you don't have to.
Network connectivity is a difficult issue. You can register notifications for when a specific network (Wi-Fi, GPRS) becomes available or unavailable. You can also set the preferred means of communication.
Make the UI as simple as possible. The user uses his thumb and/or a pen and he is probably on the move.
Test in a real device as early as possible.
"24 Hours of Windows Mobile Application Development" from the Windows Mobile Team Blog has some good resources
If you can, try to start from the user use cases and work back to the code, rather than vice versa. It's really easy to spend a lot more time working on the tools than working on the business problem. And thinking through user requirements will help you consider alternate strategies, because a lot of the patterns you know from normal .NET don't apply.
I've done lots of intermittent application development of exactly the type you are describing, and an on-board database works just fine. The MSMQ/WCF stuff just adds conceptual overhead without adding much value. You need a logical datastore locally anyway, and replication at this level is a simple concept that you want to keep simple, so the audit trail is easily monitored and debugged. MSMQ and WCF tend to hide things in unfamiliar places.
I upvoted the SqlLite suggestion BTW. MS doesn't have their persistence story stabilized yet for CE.
For the database replication bit I highly recommend Sybase Ultralite. In terms of flexibility and performance it knocks the socks off SQL CE
I had to do this once. Weird setup with Macs for development, and we were all Java programmers. And a short deadline. PowerPC macs too, so no chance to install Windows for Visual Studio development, never mind that the money for this would never have appeared.
We ended up writing applications using Java, running on the IBM J9 virtual machine, with SWT for a user interface. Entirely free development stack. Easy to deploy. Code ran on any platform we desired, not just PocketPC/WinMob.
Most of the work was on the server side anyway - the database, the web service server. The logic. The reporting engine. The client side wasn't totally simple however - would get the form templates from the server (because they changed frequently), the site details (multi-site deployment), generate a UI from the form template (using some SWT GUI components that are wonderful for PocketPC development, like the ExpandBar), gather data with a point and click interface (minimising keyboard entry where possible), and then submit it back to the server.
For offline storage we used XML files on the device itself. More than enough for our needs, but yours may differ. Maybe consider SQLite?
There are a couple links you can check out to start with:
http://developer.windowsmobile.com
http://msdn.microsoft.com/en-us/windowsmobile/default.aspx
If you have a sticking point while developing, there are also Windows Mobile dedicated chats on MSDN that you can attend and ask your questions. The calendar hasn't been updated yet, but the next ones should be in January. You can find the schedule here: http://msdn.microsoft.com/en-us/chats/default.aspx
I am going to add an additional question to this post, as its been active enough and hopefully will be helpful to others as well as me. Ok, so after playing around I now realize that standard class libraries cannot be included in windows mobile applications.
Now the overwhelming advice here seems to be use an embedded database, though I now do have use cases and it appears that I will need to have document synchronization as well as relational data. With this in mind service layer interaction seems inevitable. So my question is how would I share common domain objects and interfaces between the layers?
"Document synchronization" - does that mean bidirectional? Or cumulative write-only? I can think of mobile architectures that would mainly collect and submit transactions for a shared document - if that's your requirement, then we should discuss offline - it's a long (and interesting) conversation.
Owen you can share code from Compact Framework -> Desktop, it's only Desktop -> Compact Framework that has compatability issues if you use certain objects that are not supported by the CF.
While a desktop lib doesn't work on CF a CF lib WILL work on the desktop, you can also run CF.exes on the desktop!
Just create a CF library as the project that defines your base objects / interfaces etc.
This book sshould e essential reading for all Windows Mobile developers: http://www.microsoft.com/learning/en/us/books/10294.aspx
For developing windows mobile applications you must have the basic tools like silverlight, visual studio, windows phone emulator and sqlite as your database storage.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What options are there in the industry for enterprise reporting? I'm currently using SSRS 2005, and know that there is another version coming out with the new release of MSSQL.
But, it seems like it might also be a good time to investigate the market to see what else is out there.
What have you encountered? Do you like it/dislike it? Why?
Thank you.
I've used Cognos Series 7, Cognos Series 8, Crystal Reports, Business Objects XI R2 WebIntelligence, Reporting Services 2000, Reporting Services 2005, and Reporting Services 2008. Here's my feedback on what I've learned:
Reporting Services 2008/2005/2000
PROS
Cost: Cheapest enterprise business intelligence solution if you are using MS SQL Server as a back-end. You also have a best-in-class ETL solution at no additional cost if you throw in SSIS.
Most Flexible: Most flexible reporting solution I've ever used. It has always met all my business needs, particularly in its latest incarnation.
Easily Scalable: We initially used this as a departmental solution supporting about 20 users. We eventually expanded it to cover a few thousand users. Despite having a really bad quality virtual server located in a remote data center, we were able to scale to about 50-100 concurrent user requests. On good hardware at a consulting gig, I was able to scale it to a larger set of concurrent users without any issues. I've also seen implementations where multiple SSRS servers were deployed in different countries and SSIS was used to synch the data in the back-ends. This allowed for solid performance in a distributed manner at almost no additional cost.
Source Control Integration: This is CRITICAL to me when developing reports with my business intelligence teams. No other BI suite offers an out-of-box solution for this that I've ever used. Every other platform I used either required purchasing a 3rd party add-in or required you to promote reports between separate development, test, and production environments.
Analysis Services: I like the tight integration with Analysis Services between SSRS and SSIS. I've read about instances where Oracle and DB2 quotes include installing a SQL Server 2005 Analysis Services server for OLAP cubes.
Discoverability: No system has better discoverability than SSRS. There are more books, forums, articles, and code sites on SSRS than any other BI suite that I've ever used. If I needed to figuire out how to do something in SSRS, I could almost always find it with a few minutes or hours of work.
CONS
IIS Required for SSRS 2005/2000: Older versions of SSRS required installing IIS on the database server. This was not permissible from an internal controls perspective when I worked at a large bank. We eventually implemented SSRS without authorized approval from IT operations and basically asked for forgiveness later. This is not an issue in SSRS 2008 since IIS is no longer required.
Report Builder: The web-based report builder was non-existant in SSRS 2000. The web-based report builder in SSRS 2005 was difficult to use and did not have enough functionality. The web-based report builder in SSRS 2008 is definitely better, but it is still too difficult to use for most business users.
Database Bias: It works best with Microsoft SQL Server. It isn't great with Oracle, DB2, and other back-ends.
Business Objects XI WebIntelligence
PROS
Ease of Use: Easiest to use for your average non-BI end-user for developing ad hoc reports.
Database Agnostic: Definitely a good solution if you expect to use Oracle, DB2, or another database back-end.
Performant: Very fast performance since most of the page navigations are basically file-system operations instead of database-calls.
CONS
Cost: Number one problem. If I want to scale up my implementation of Business Objects from 30 users to 1000 users, then SAP will make certain to charge you a few hundred thousands of dollars. And that's just for the Business Objects licenses. Add in the fact that you will also need database server licenses, you are now talking about a very expensive system. Of course, that could be the personal justification for getting Business Objects: if you can convince management to purchase a very expensive BI system, then you can probably convince management to pay for a large BI department.
No Source Control: Lack of out-of-the-box source control integration leads to errors in accidentally modifying and deploying old report definitions by mistake. The "work-around" for this is promote reports between environments -- a process that I do NOT like to do since it slows down report development and introduces environmental differences variables.
No HTML Email Support: You cannot send an HTML email via a schedule. I regularly do this in SSRS. You can buy an expensive 3rd party add-in to do this, but you shouldn't have to spend more money for this functionality.
Model Bias: Report development requires universes -- basically a data model. That's fine for ad hoc report development, but I prefer to use stored procedures to have full control of performance. I also like to build flat tables that are then queried to avoid costly complex joins during report run-time. It is silly to have to build universes that just contain flat tables that are only used by one report. You shouldn't have to build a model just to query a table. Store procedure support is also not supported out of the box without hacking the SQL Overrides.
Poor Parameter Support: Parameter support is terrible in BOXI WebIntelligence reports. Although I like the meta-data refresh options for general business users, it just isn't robust enough when trying to setup schedules. I almost always have to clone reports and alter the filters slightly which leads to unnecessary report definition duplication. SSRS beats this hands down, particularly since you can make the value and the label have different values -- unlike BOXI.
Inadequate Report Linking Support: I wanted to store one report definition in a central folder and then create linked reports for other users. However, I quickly found out end-users needed to have full rights on the parent object to use the object in their own folder. This defeated the entire purpose of using a linked report object. Give me SSRS!
Separate CMC: Why do you have to launch another application just to manage your object security? Worse, why isn't the functionality identical between CMC and InfoSys? For example, if you want to setup a scheduled report to retry on failed attempts, then you can specify the number of retries and the retry interval in CMC. However, you can't do this in InfoSys and you can't see the information either. InfoSys allows you to setup event-driven schedules and CMC does not support this feature.
Java Version Dependency: BOXI works great on end-user machines so long as they are running the same version of java as the server. However, once a newer version of java is installed on your machine, things starts to break. We're running Java 1.5 on our BOXI R2 server (the default java client) and almost everyone in the company is on Java 1.6. If you use Java 1.6, then prompts can freeze your IE and FoxFire sessions or crash your report builder unexpectedly.
Weak Discoverability: Aside from BOB (Business Objects Board), there isn't much out there on the Internet regarding troubleshooting Business Objects problems.
Cognos Series 8
PROS
Ease of Use: Although BOXI is easier to use for writing simple reports for general business users, Cognos is a close 2nd in this area.
Database Agnostic: Like BOXI this is definitely a good solution if you expect to use Oracle, DB2, or another database back-end.
FrameWork Manager: This is definitely a best-in-class meta-data repository. BOXI's universe builder wishes it was half as good. This tool is well suited to promoting packages across Development, Test, and Production environments.
CONS
Cost: Same issue as Business Objects. Similar cost structure. Similar database licensing requirements as well.
No Source Control: Same issue as Business Objects. I'm not aware of any 3rd party tools that resolve this issue, but they might exist.
Model Bias: Same issue as Business Objects. Has better support for stored procedures in FrameWork Manager, though.
Poor Parameter Support: Same issue as Business Objects. Has better support for creating prompt-pages if you can code in Java. Buggy behavior, though, when users click the back-button to return to the prompt-page. SSRS beats this out hands-down.
Inadequate Error Handling: Error messages in Cognos are nearly impossible to decipher. They generally give you a long negative number and a stack dump as part of the error message. I don't know how many times we "resolved" these error messages by rebuilding reports from scratch. For some reason, it is pretty easy to corrupt a report definition.
No Discoverability: It is very hard to track down any answers on how to troubleshoot problems or to implement functionality in Cognos. There just isn't adequate community support in Internet facing websites for the products.
As you can guess from my answer, I believe Microsoft's BI suite is the best platform on the market. However, I must state that most articles I've read on comparisons of BI suites usually do not rate Microsoft's offering as well as SAP's Business Objects and Cognos's Series 8 products. Also, I've also seen Microsoft come out on the bottom in internal reviews of BI Suites in two separate companies after they were review by the reigning CIO's. In both instances, though, it seemed like it all boiled down to wanting to be perceived as a major department that justified a large operating budget.
I'd like to make two contributions. One is very negative (CR is rubbish) and the other is very positive (SSRS is backing store independent and available at no cost).
On a side note, if you mod an answer down then add a comment explaining why you think the answer is wrong or counterproductive, unless someone else already said the same thing. Even then, a simple "as above" would be helpful.
Crystal Reports is rubbish
Crystal Reports is an insult to the development community. Simple dialog resize bugs that would be the work of moments to fix have remained uncorrected over ten years and six major releases, so I really doubt that any attempt is ever made to address the tough stuff. Crystal Reports is profoundly untrustworthy, as this SQL demonstrates.
SELECT COUNT(*) FROM sometable WHERE 1=0
This statement produces a result of one when it should produce zero. This is a repeatable off-by-one error in the heart of the Crystal Reports SQL engine.
The support for CR is equally dismal, having been moved offshore many years ago. If you cough up $200 for a support call, an unintelligible foreigner will misunderstand your question and insult your intelligence until you give up, at which point he will - because you have chosen to give up - declare the call resolved.
If it's really this bad why is it so popular? It isn't popular. It's very un popular. It gets a toe-hold via great marketing. Management types see glossy adverts promising much, and because CR has been around so long they assume it's all true. Much like bindis (Australian prickle weed) in your lawn, once installed it's nearly impossible to get rid of it. Admitting to incompetence is a bad career move for a manager. When managers lack the technical expertise to make a decision, rather than allow a technical person to make the decision they fall back on precedent and repeat the mistakes of their peers. They also fail to realise that if they want to actually use the web delivery stuff they are up for a server licence. Also, longevity means it's easy to find people with CR experience.
For the details and a good laugh I recommend these links.
Clubbing the Crystal Dodo
Crystal Reports "Sucks"
[Crystal Reports Sucks Donkey Dork ] (dead link, still trying to find content) 3
Or just type "crystal reports sucks" into Google. For a balanced perspective, also try "crystal reports rocks". Don't worry, this won't take much of your time. There are no positive reviews outside their own marketing hype.
Now for something more positive.
SQL Reports is effectively free
You can install it at no charge as part of SQL Express with Advanced Services. You can also install .NET 2.x which brings with it ADO.NET drivers for major database providers as well as generic OLEDB and ODBC support.
Since SSRS uses ADO.NET, this means you can connect SSRS to anything to which you can connect ADO.NET, ie just about anything.
The terms of the licence applying to SSRS as supplied with SQL Express require it to be deployed and installed as part of SQL Express. They don't have anything to say about where reports get their data.
SQL Express is limited, but the accompanying SSRS has no such limitations. If your data is provided by another database engine you can support as many users as that engine is licensed to support. Don't get me wrong, at work we have dozens of licensed copies of MS SQL Server. I'm just saying that you can use SSRS against the backing store of your choice, without having to find or justify budget for it. What you will be missing is scheduling and subscription support. I speak from experience when I say that it is not profoundly difficult to write a service that fills the gap.
SSRS fulfils every promise that CR makes. Easy to use, good support for user DIY, has a schema abstraction tool conceptually similar to CR BO but which works properly, high performance, schedulable, easy to use, stable, flexible, easy to extend, can be controlled interactively or programmatically. In the 2008 edition they even support rich-formatted flow-based templates (mail merge for form letters).
It is the best reporting solution I have ever seen in twenty years of software development on platforms ranging from mainframes through minis to micros. It ticks every box I can think of and has only one profound weakness I can recall - the layout model doesn't support positioning relative to page bottom and the only workaround is positioning relative to page top on a known height page.
It does not address problems like heterogeneous data provision, but IMHO these can and should be addressed outside of the report proper. Plenty of data warehousing solutions (such as SSIS) provide tools for solving such problems, and it would be absurd to put a half-assed duplicate capability in the report engine.
Getting a sane decision out of your pointy-haired boss
Tell him you think that given its problematic history and unpopularity with developers, choosing Crystal Reports is a courageous move that marks him as a risk-taker.
Some bosses are so stupid they will think this is a good thing but with them you are doomed anyway.
Having experiences with both (CR and SSRS) here is the lowdown of what I think:
CR lets you develop a report very fast. As long as its simple. If it gets slightly complicated, it gets fishy trying to make it do what you want. Per example you are limited to a max hierarchy of 2 subreports. It gets weird when you have subreports that need parameters that must be altered in a main report, etc. Plenty of workarounds but sometime they simply suck.
Also the report layout is basically fixed; you have to put your data and info into the specific sections (Page Header/Footer,Details/Report Footer/Header). This is rather helpful as it helps you correctly display data that spans on multiple pages.
Also it has a fairly complete set of functions that can be used to manipulate financial data and etc.
SSRS is more flexible around the report editing. Its report wizard allows you to basically create a report in a WYSIWYG environnement, it allows you multiple subreports so you can easily display multiple datasets in one page. It allows you to connect .NET assemblies to do complicated data manipulation/calculation. However, it can get hard to properly display your reports in a fixed way, you often have to struggle to get everything displayed as you want it.
Crystal Reports is $$$.
SSRS, if I remember correctly is now bundled "free" in the SQL Server Enterprise edition. Of course you probably pay for it in the price of the whole package, I guess it's MS way to try and push it in corporate land.
I've been using SSRS for a while now... and coworkers who look over my shoulder say it looks to be MUCH easier to do the SSRS thing than the Crystal. I've never used Crystal, so I can't tell you which is better, but I get the distinct impression that MS tried to rush SSRS out the door.
Largest weaknesses:
Sharing Datasets. I work in a DoD environment. 90% of my reports use a Service parameter. I get sick of typing the same query over and over again.
Skinning. If you do the report wizard you can skin your report, but not if you do
it manually? huh? I can "skin"things by selecting all the affectedfields and then setting back colors,fore colors, etc. But nowhere (atleast no where I can find) can youskin something with 1 click.
No custom skinning. Report wizard/
manual, there's no where I can find
to implement a custom skin. Would
be nice to just set up something
(like CSS for HTML) and then just
link to it. Tools should help you by reducing your effort rather than add to said effort.
Matrixes need better documentation. I can do VERY simple things, but once I try to get into fun/difficult things, books/the internet seem to let me down. Tables don't have this issue.
Strengths:
Very simple for an old SQL developer to get good reports that at least look better than the drek that dumping a restlt set to Excel provides.
Custom sorting (use on most reports)
Handles SP and Straight SQL. Love that I'm not locked into 1 path or the other (I've used both depending on circumstances).
Price... once you've paid for Visual Studio/SQL Server... it's a freebie.
My 2 cents, hope this helps you.
A "pure Java" solution is i-net Clear Reports (aka i-net Crystal-Clear).
Supports Crystal Reports templates as well as any JDBC data source.
Comes with a FREE visual report designer.
Good price for what it does, especially in comparison to some of the "pricier" alternatives.
The latest version includes a web-based configuration tool as well as an ad-hoc report creation tool.
Has a .NET port (with extensive API)
There are a number of really great solutions out there for Enterprise Reporting. Within the big four (BO/Crystal, MS SRSS, Cognos, Oracle) the basic reporting functions are all covered. You really need to evaluate what core functionality is most important to you and what the pre-dominant architecture in your environment is.
The consolidation within the BI market has made the environment issue all the more relevant. If you have an Oracle enterprise, you may as well use Oracle BI. The same applies for SAP/BO, IBM/Cognos, and Microsoft. Particularly if you are making a new BI decision.
Finally, there are a number of Open Source solutions (BIRT, Jasper, Pentaho) that make sense if you are an OSS shop or if you are looking to avoid some of the licensing fees associated with the major BI players.
You should try BIRT. BIRT is open source so you can start for free. It has a nice graphical designer. You can see some videos of how easy to design BIRT reports at http://www.birt-exchange.com. The BIRT project was sponsored by Actuate Corp who offers commercial servers for deploying BIRT to the Enterprise when you need scheduling, security integration, email notifications, etc. The commercial version also mixes AJAX with the BIRT viewer for more end-user interactivity and offers ad-hoc BIRT reporting through a browser.
We are in the middle implementing Cognos right now, and I really think it's a fairly robust tool. The ETL tool seems pretty straightforward and easy to use and the front end is fairly easy to administer and set up. I don't have much experience in the framework models and the data modeling stuff, but our report designer guy really seems to like it.
One of the most comprehensive solutions is Cognos.
Dislike: You wouldn't believe how many CDs it ships in... its huge.
I'm suprised no-one has mentioned Microstrategy. We do quite a bit of datawarehouse (11TB) work and microstrategy does a great job or generating SQL so the business users can get the data without bothering us. However it is a very expensive solutuion. if you don't need ad-hoc abilities and decide on crystal i recommend lookin into their VS2005 or Eclipse plugins which are "fre for production use".
In his blog at SAP Community Website, Henry Nordstrom, has given a very good evaluation of various reporting tools available. Though he has done the same from SAP usage point of view, the facts are applicable to anything else also.
Henry's Blog on SAP Developer Network
I'm surprised nobody mentioned OpenReports with Jasper report templates. I know it's not quite enterprise level, but it's quite powerful and I think on par with Crystal Reports. I use iReport to create CR-like reports. OpenReports also supports JXLS which is very easy to use to create Excel-based reports.
http://oreports.com/
http://jasperforge.org/projects/ireport
Crystal Reports by Business Objects seems to be a popular choice.
I never wrote any reports in it myself, but others in my team who did sometimes struggled getting the more complex reports to work.
It also might be a bit pricey, depending on your budget.
If you want an enterprise-class report server that works with ANY report designer you want to use, check out Universal Report Server from VersaReports.com. Out-of-the-box it supports Crystal, DevExpress, Telerik, and ActiveReports, and provides an API if you want to support another report designer.