This product by [not of your]Business Objects does not seize to amaze me. I have already given up trying to figure it out for a while now, but every once and a while I bump into one of its challenging riddles and get forced to figure things out.
So the story:
While developing an ASP.NET application I have to deploy versions of it for testing, so I keep separate Database (Oracle) schemas with different users. For example: db1 where the user is db1, db2 where user is db2 and so on. And I just backup the existing working db and create a new one so there would be no conflict since someone might still be working on db1. And this happens on both my development and testing machines, so on my PC we have db1, db2, ... dbn, and on the testing machine db1, db2, ... dbn. So now we are happily testing our reports, and we notice some strange behavior (after a lot of shooting in the dark), we notice that the reports residing on the test machine are still querying data from the old database!! Hmmm, someone might wonder if I changed the mapping in the reports, well I did not, because that happens at runtime through my ASP.NET code which was tested before and should in theory still work. This piece of code actually gets its configuration from the connection string in my web.config file. And I double checked that my web.config file has the correct connection string to the correct new db. After a lot of those moments where you fake those looks of wisdom in front of the client (freaking out in front of a client: Not a great idea), I just get one of those "House" moments where it hit me: something, somehow is getting data from the database. What is it?? I looked around in the menu options and noticed a check near "Crystal Reports --> Database --> Verify on Every Print". The way I would understand it is that this option is supposed to verify that the data in the displayed report is not stale. But what I would not have usually guessed is that this option might get the data from the wrong database. Yes that was it, the data was being fetched from the wrong database, the database could be the one I had set during development, or not, who cares?? All I cared about at that time is that the problem was solved. All I had to do was uncheck that option and I was on the go.
So, conclusion???
Get another reporting solution. I actually am considering alternatives, especially those that support Objects instead of mere DataSets.
So the story:
While developing an ASP.NET application I have to deploy versions of it for testing, so I keep separate Database (Oracle) schemas with different users. For example: db1 where the user is db1, db2 where user is db2 and so on. And I just backup the existing working db and create a new one so there would be no conflict since someone might still be working on db1. And this happens on both my development and testing machines, so on my PC we have db1, db2, ... dbn, and on the testing machine db1, db2, ... dbn. So now we are happily testing our reports, and we notice some strange behavior (after a lot of shooting in the dark), we notice that the reports residing on the test machine are still querying data from the old database!! Hmmm, someone might wonder if I changed the mapping in the reports, well I did not, because that happens at runtime through my ASP.NET code which was tested before and should in theory still work. This piece of code actually gets its configuration from the connection string in my web.config file. And I double checked that my web.config file has the correct connection string to the correct new db. After a lot of those moments where you fake those looks of wisdom in front of the client (freaking out in front of a client: Not a great idea), I just get one of those "House" moments where it hit me: something, somehow is getting data from the database. What is it?? I looked around in the menu options and noticed a check near "Crystal Reports --> Database --> Verify on Every Print". The way I would understand it is that this option is supposed to verify that the data in the displayed report is not stale. But what I would not have usually guessed is that this option might get the data from the wrong database. Yes that was it, the data was being fetched from the wrong database, the database could be the one I had set during development, or not, who cares?? All I cared about at that time is that the problem was solved. All I had to do was uncheck that option and I was on the go.
So, conclusion???
Get another reporting solution. I actually am considering alternatives, especially those that support Objects instead of mere DataSets.
0 comments:
Post a Comment