We have the standard 3 environment setup of development, testing and production. Each environment has their own report server, web server, database server, etc.
Part of our migration is to move our business objects (xi r2) reports between the servers but as of right now we need to manually update the connection settings for each report. This is mildly painful now at 40+ reports and will become a nightmare as we continue.
Due to how we generate reports we cannot dynamically change the connection string when we generate the report. We are using stored procs instead of Universes because that is what the team is most familiar with.
Any suggestions would be greatly appreciated.
There is an API that you can use to programatically update this sort of thing, although I can't remember how to do it. Check out the docs provided by Business Objects - IIRC they are not publically available (at least they weren't in 2006 when I last worked with it) so you may have to get them from the vendor.
Take a look at the Report Class' ReportLogon Class in the CrystalDecisions.Enterprise.Desktop.Report Assembly of the BusinessObjects SDK. Quite a few options for changing the database connection.
I wrote something similar for a client to make bulk changes Universes and WebI reports. I would imagine that it is very similar for Crystal Reports.
Are you changing the Universe Connection or Universe themselves?
In our environment, we worked around this by having the Universes named the same between environments but they each have a different Connection by environment. This prevents needing to change each report.
I searched far and wide and it seems like this is an unusual circumstance. My final solution which seems to be okay is to have a consistent DSN connection string in each environment. This means that each connection string is effectively the same.
It still feels wrong and if anyone has other ideas that would be great.
EDIT:
This failed miserably after a little bit of testing I found out many of our stored proceedures would not run using the DSN. After that I gave up completely.
Related
I have a program written in VB due to the simplicity and GUI when using Visual Studio 2010 as my IDE and compiler. In this program I built a "ticketing" system where approximately 40 users in my center have the authority to submit tickets to my coworkers and I for IT or Facilities assistance.
This system uses an access database on the local server using SQL as the language. The problem is that we have rare occurrences where two users are trying to write a "ticket" at the same time to the database or pull a report of the data at the same time from the database and it crashes on one of users. I use a "try, catch, finally" block to avoid the "unhandled exception error" and have the program setup that should an "unhandled exception error" occur that it closes automatically. The other concern is that once this collision has occurred, the user can no longer read/write to the database through the program until they restart their computer.
With all that in mind, my question is as follows, is there a 100% way to prevent these collisions from occurring (like checking if the database is in use before reading/writing) and if not is there a way to avoid them being locked out of the database until restarting their computer?
Since this post I have swapped to a virtual MySQL database server to run these at much better speeds. The issue I was having however, was resolved by clearing the pool. Since at the time I was using OLEDB I used the command:
OLEDBConnection.ReleaseObjectPool()
and it prevented any more of these computers being locked to where they had to restart the computer as well as help prevent collisions.
Assuming you are using OLEDB, you can try using Transactions, which are simple to implement as explained in the Developer Network article entitled OleDbConnection.BeginTransaction Method.
I must admit I do not understand the IsolationLevel settings, but try omitting it or using the default shown in the example before trying the other available cryptic ones.
As Tony suggests, converting to SQL-Server is a much more robust (long-term) solution that will ensure data integrity, especially if you plan to add more users. MS has a free migration tool that does an excellent job, even on queries. As for data integrity, see the last paragraph in the Microsoft Support article: Using Microsoft Jet with IIS
I develop a software system that runs on multiple computers that connect to a centralized database.
At this point in time, all SQL queries are inline with the applications source code. I would like to start migrating these into stored procedures.
If I need to make a change to a stored procedure that will require a software change, how can I synchronize the updates? For example: I change sp_SelectRecordByID and publish an update for the software. Immediately, all running software versions will receive an error upon running sp_SelectRecordByID. Once they crash and the update is received, all is good.
How do I prevent this scenario?
I've come up with a few ideas:
Make a new stored procedure and let the old one die off slowly
Add version checking to the stored procedure. This is highly undesirable.
Are there more effective methods or am I stuck with these options?
From what I understood this is more of a deployment issue. The way I see it there are couple options.
If you can deploy SQL Server and application changes simultaneously (or at least near to that) then you can just publish both at the same time but I guess it depends on the system.
Can you do this over the weekend when there is no risk of applications crashing?
Do you deploy the new application version to all users at once? If yes then you can just create new SP first, deploy new application version and then delete old SP.
Anyway, hope this helps. If not, please provide more details on number of servers, number of client applications and such…
Are you using Visual Studio? You can keep your stored procedures in a database project and have version control this way.
More info in here: http://msdn.microsoft.com/en-us/library/xee70aty.aspx
I have been using MS Access databases via DAO for many years, but feel that I ought to embrace newer techniques.
My main application runs on end user PCs (no server) and uses a shared database that is created and updated on-the-fly. When the application is first run it detects the absence of a database and creates a new empty one.
Any local user running the application is allowed to add or update records in this shared database. We have a couple of other shared databases, that contain templates, regional information, etc., but these are not updated directly by the application.
Updates of the application are released from time to time and each new update checks the main database version and if necessary executes code to bring the database up to the latest specification. This may involve the creation or deletion of tables and/or columns. New copies of the template databases are also included as part of the update.
Our users are not required to be computer-literate and should not need to run any sort of database management software beyond those facilities provided by the application.
It all works very nicely with DAO/Access, but I'm struggling to find how to do it with SQL Express. The databases seem to be squirrelled away in locations that are user-specific and database creation and update seems at best awkward to do by program code alone.
I came across some references "Xcopy deployment" that looks like it could be promising, but there seem to be references to "user instances" that sound suspiciously like something that's not shared. I'd appreciate advice from anyone who has done it.
It sounds to me like you haven't fully absorbed the fundamental difference between the Access Database Engine (ACE/Jet) and SQL Server:
When your users launch your Access application it connects to the Access Database Engine that has been installed on their machine. Their copy of ACE/Jet opens the shared database file (.accdb or .mdb) in the network folder. The various instances of ACE/Jet work together to manage concurrent updates, record locking, and so on. This is sometimes called a "peer-to-peer" or "shared-file" database architecture.
With an application that uses a SQL Server back-end, the copies of your application on each user's machine connect over the network to the same instance of SQL Server (that's why it's called "SQL Server"), and that instance of SQL Server manipulates the database (which is stored on its local hard drive) on behalf of all of the clients. This is called "client-server" or "server-based" database architecture.
Note that for a multi-user database you do not install SQL Server on the client machines, you only install the SQL Server Client components (OleDb and ODBC drivers). SQL Server itself is only installed in one place: the machine that will act as the SQL... Server.
re: "database creation and update seems at best awkward to do by program code alone" -- Not at all, it's just "different". Once again, you pass all of your commands to the SQL Server and it takes care of creating the actual database files. For example, once you've connected to the SQL Server if you tell it to
CREATE DATABASE NewDatabase
it will create the database files (NewDatabase.mdf and NewDatabase_log.LDF) in whatever local folder it uses to store such things, which is usually something like
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA
on the server machine.
Note that your application never accesses those files directly. In fact it almost certainly cannot do so, and indeed your application does not even care where those files reside or what they are called. Your app simply talks to the SQL Server (e.g. ServerName\SQLEXPRESS) and the server takes care of the details.
Just to update on my progress. Inspired by suggestions here and this article on code project:
http://www.codeproject.com/Articles/63147/Handling-database-connections-more-easily,
I've created a wrapper for the ADO.NET methods that looks quite similar to the DAO stuff that I am familiar with.
I have a class that I can use just like a DAO Database. It wraps ADO methods like ExecuteReader, ExecuteNonQuery, etc. with overloads that can accept a SQL parameter. This allows me to directly replace DAO Recordsets with readers, OpenRecordset with ExecuteReader and Execute with ExecuteNonQuery.
Each method obtains and releases the connection from its parent class instance. These in turn open or close the underlying connection as required depending on the transaction state, if any. So a connection is held open for method calls that are part of a transaction, but closed immediately for a single call.
This has greatly simplified the migration of my program since much of the donkey work can be done by a simple "find and replace". The remaining issues are then relatively easy to find and sort out.
Thanks, once again to Gord and Maxwell for your advice.
This answer is too long to right down... but go to Microsoft page, there they explain how to make it: http://office.microsoft.com/en-us/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx
I hope this help you!!
Assuming the databases have the exact same structure(just different data)
How would this be done? I'm guessing if I give the datasources the same name I could just deploy the report(rdl) without changing anything, right? This is using ssrs 2008.
Different organizations would be using the reports on their own databases and webservers, and I'd like to know how hard it would be to deploy reports at each organization within a reasonable ammount of time.
We were using 2008 R2 and it was probably even easier than that. We just swapped out connect strings and kept the datasources named the same when deploying.
You can set the datasource's connection when you deploy, which is exactly what we do when a report runs in our dev, test then live servers which obviously have different database servers. Even your datasource name can be different , this can be set in the properties of the report once it has been deployed.
As long as you're setup to use shared datasources, then it's just a matter of configuring the datasource correctly on deployment. This should really be a very easy operation.
So I've created an Access Project for one of my users so he can connect to a reporting database. The .adp project connects to the DB and he can query data to his heart's content. The problem is, no queries can be saved. Whenever he opens the project, he is presented with the following error:
"This version of Microsoft Access does not support design changes with the version of Microsoft Sql Server to which your Access project is connected. See the Microsoft Office Update Web site for the latest information and downloads. Your design changes will not be saved."
Again, this is Access 2007 and Sql Server 2005. My googling efforts - which are coming on a day when I seem to be especially stupid - keep bringing up information regarding this error for Access 2002/2003 trying to connect to Sql Server 2005, which is clearly not my problem.
I'm seeing that one can connect to Sql Server with the normal Access databases (.accdb in 2007 or some such), but I'm seeing mixed information regarding whether I want to do this or not. And since I can't get a copy of Access 2007, I can't really test this (topic for another time).
Before I do down that road, I'd like to get to the bottom of this one. Anyone have any suggestions, useful links, or useful knowledge? Or an older developer who knows the answer that is no longer needed, so I can eat him and absorb his knowledge and powers?
The account being used to connect to the DB was only a db_reader. I changed it to DBO and that fixed the problem - user can now create and save queries, and sleep at night knowing that tomorrow will bring a new day with new querying possibilities.
I'm not super crazy about this though the reporting database has been set up on a separate install/server from impotant App databases. I'm not worried about the user (or anyone on his group) blowing anything up. I'd like to understand why this is, and don't (outside of the obvious - reader is read only! I didn't expect that to extend to work in Access), and will try to do so at a later time. One of the unfortunate aspects of working at a dev shop focused on internal app development is, "well, it's working, you have other things to see to".
I am not sure if I can be of help here.
But you can have a view inside Access which connects to SQL database and use that view.
Alternatively, you can go the other way. Have a DB project with SQL Server & create a linked server to MS-Access DB.
Did you try linking to the tables through an ODBC connection?
CodeSlave, I did not. The attitude from higher up is "it's working, move on". I'm not sure the boss really wanted to go down that road anyway, but it's a moot point. I should probably try granting the account dbreader and dbwriter access and see if that accomplishes the same thing, but it being dbo isn't really a huge deal. Or rather, it's not a big enough deal that The Powers That Be want me to seek an immediate change.
I was going to try linked tables until changing the SQl Server account permissions "fixed the problem" (quotes very deliberate; it feels like one of those solutions you arrive at without a proper understanding of what it worked, which vexes me).