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
Related
I am not very familiar with Access database till now i was only programming to SQL Server but now it's time to do so. I am building WinForms application which will be using Access database and i have some question related to that point if you don't mind. My application will be used by multiple users and there will be one access databsae. My questions as below:
Is there any problem with accessing access database in same time by many users or only one user can be connected?
If i develop my program to use access 2016 and some of my users will have diffrent windows version and also diffrent access version
will it works?
Should i know something else? :)
If your client want to have a file based database and this is a project constraint , MS Access is the best choice. If you want a more detailed advice, please let me know how many users will perform Read/Write or Read transactions, the size of the database and if the application will run in client-server mode in a LAN/WAN, Cloud or Remote Desktop environment.
Back to your questions:
Depending on these conditions you may range from 10 to 20/25 users. Remember that you can always try with MS Access and later upgrade to a MS SQL database in a couple of hours.
If your front-end application can link to a 2016 Access database, it will do that without installing MS Access to the clients that will run your App, i.e. the vb.net compiled App will install all needed drivers. If you develop your App within MS Access 2016 (Access Form and reports, some VBA) you can run it with the free runtime version of MS Access, but this only when no older version of Access is installed on the running workstation.
Please check with your client the real reasons for a file-based database...
To answer the questions as asked:
You might run into an issue with this, as access was really designed as a personal use database. Having anything more than a small handful of users hitting against it at once will in fact cause problems, as it's not really well designed for that purpose...
This should in theory be fine, as the application itself is interfacing with the database, not the end user...
It seems like you're taking a step backwards using access for this, and SQL might very well be better suited for this purpose. This isn't me trying to just bash access either, this comes from personal experience. Going with this sort of design is likely to cause you more headaches than good.
On my development box, I always run the latest version of SQL Server. I often deploy databases from my dev box to a live/staging area for review or testing. I've done this many times and it has always been a painful process, but I am realizing that I need to find an easier, more reliable and consistent way of performing this basic operation.
I normally use WebMatrix purely for deployment and it's worked fine, but I've been having problems getting it to work on my server for some reason. Consequently, I am seeking an alternative solution.
Creating a SQL dump file would probably work, but it's not an acceptable solution a database contains images and easily exceeds 2 gigs of data which would take forever.
The Import/Export utility fails due to issues with incomplete schema copies, identity inserts and checks. The solutions offered for these issues has failed to work in my particular case.
The Backup and Restore method also fails due to some strange incompatibilities between SQL Server 2008 and 2012. SQL Server 2008 Management Studio throws exceptions during the restore process of a 2012 database. It's odd that this happens, even though I set the compatibility of the database to version 2008.
I haven't tried the Detaching, copying and reattaching files method, but I haven't bothered trying since it would probably fail for the same reasons the backup and restore method did.
Are there other alternatives out there? Also, why is this so unbelievable hard for a task that is so common and important, especially in this day in age of 2013? Get real Microsoft!
We changed our method of deploying and moving databases between servers, instances and versions by adopting the tools from RedGate. They are expensive, but worth it IMHO.
My team creates scripts for ~everything.
Database Creation, Alter, Inserts, etc, etc.
And we write all scripts that check for the existence of things before trying to create them.
Aka, we can run the scripts over and over and get the same results.
And we deploy to different environments by using SqlCmd.exe.
EDIT
See:
http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-views-stored-procedures-and-the-like.aspx
and
http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx
=============
If that is "too much" then I agree with the other poster, RedGate is your friend.
Points below aside, have you considered the Database Projects within VS2012? they allow you to script off the tables, sp's, triggers, users etc you want, generate sql cmd scripts, make changes and schema compare and version control your database code, I'd certainly recommend it
"Creating a SQL dump file would probably work, but it's not an
acceptable solution a database contains images and easily exceeds 2
gigs of data which would take forever."
Why is this a problem? where are you transferring the file from and to and over what connection?
"The Backup and Restore method also fails due to some strange
incompatibilities between SQL 2008 and 2012. SQL 2008 Management
Studio throws exceptions during the restore process of a 2012
database. It's odd that this happens, even though I set the
compatibility of the database to version 2008"
This shouldn't be an issue if file is created in 2008 prior to restoring. If you create a new DB in your 2008 instance, then take a backup from that and restore it to a 2012 instance with 2008 compatiblity, then you should be able to use it there, back it up from the 2012 instance and restore to 2008 again afterwards.
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!!
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.
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).