I'm working on a program that needs to edit some objects in an Access database. It also runs a subprogram (long story) that tries to access the underlying JET database while Access still has it open via ODBC.
The problem is that as soon as I start editing Form objects using VBA - for example, using Application.LoadFromText - Access changes the database to exclusive mode. Exclusive mode itself is fine, and I know why it needs it. But I need to be able to switch back to "shared" mode afterwards so that I can run my subprogram.
I've observed that if you use the UI to open a Form in Design mode, Access switches the database to Exclusive. (You can confirm this by trying to open it from another computer.) But when you then close the form designer, Access immediately switches it back to shared mode, which is what I would hope for.
Is there a way to switch it back and forth myself using VBA / COM calls?
I know I can call Application.CloseCurrentDatabase() followed by OpenCurrentDatabase(), but that closes all the windows and upsets the UI, so it's not ideal.
Is splitting the database into a separate front-end with the forms/modules/etc. and back-end with the tables an option? That way if the front-end is locked, the back-end is still accessible. Access has a database splitting wizard for just that.
You might try .UserControl and .Visible. I use them to transfer control in automated processes.
Related
When multiple users open my windows application, it shows a warning saying it(accdb) is already in use. How do I allow multiple users to make entries using my application simultaneously?
The database which my application is using is in shared mode.
edit :
here's a snap of the error that pops up:
You may consider making the application talk to database, and then allowing the users to use their own copy of the application. This way, only one user is using the application, but multiple instances access the database.
I am new in vb.net programming. Am facing a problem in database handling. Am using oledb to deal with database, which is MS Access in my project. I am dealing with queries at the time. Now the problem is that my queries are working well on vb form but are not affecting the actual database. For example, when am adding a record, it displays 'record added successfully', the message I have used for my conformation, but the actual database is not displaying the record I just entered and even got the above conformation message as well. I have checked query in sql editor too, its doing well. I have checked locals in vb debug mode, all are containing correct values.
Am not getting what's the reason behind that. Why it is displaying the success message but not modifying the actual database. Same is the case when am firing delete query, till now. I have not tried Update query yet.
Technology - Visual Basic.net with MS Access
Am using Access 2007 and Visual Studio 2013
Please Help by your suggestions
Do the controls on your form have the correct control source, i.e. the database table/query from and to which it should be reading and writing to?
Basically the problem was the gap between my understanding and .Net's working.
Here is the solution.
You can include database in two ways:
1.Either importing it directly to your project from the place, for example using drag and drop, or some other such method.
2.Or, by including it via using wizard.
But, the difference lies in connection string you use in your project, if you give absolute path of database, then you will directly see the alterations in database you have done using your application, even in testing and debugging mode via IDE.
connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\xyz.accdb"
But if you are using connection string provide by wizard, for example,
connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\xyz.accdb"
what the IDE will be doing is whenever you will be running project for debugging or testing, every time, it will copy the actual database, with its contents as well, in /bin/Debug folder. So, the changes you are performing will only be visible to that copy, not the actual file. So, if you want to verify with the database, like in our case, check the copy of database, which will be present in /bin/Debug folder. You will see the changes there. But, every time you run project for debugging, it will replace that copy with original one.
So, actually I was checking the original database file, not that copy, since the changes were only made to that copy. So that is why I was facing the above problem, not due to any programming fault.
I am coming from a php background background where we remotely connect to the database and manipulate everything with php code. Now in vb.net, will the performance of my desktop application be affected in anyway if i connect manually in the form_load event event instead of vb.net database source connection?
i come from both backgrounds.
yes you can manually open database BUT
you should specify the database you are using to make the best performance in your desktop application, for example:
in access database (mdb files), you should open the database once in form_load, and use it all the time, then close it before exitting the application in form_closing (this is for better performance)
while in SQL Server, you should open the database for each function then do your queries then close it after you finish.
Create a DataAccessClass.
Do your db functions in this class (update functions, select functions etc)
Connect to the db on class instantiation.
give your class the necessary work to do, and receive answers back from the class.
In essence, extract your data access from your forms, so that you can reuse your data class anywhere in your app
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!!
I am here to write a small database application that will be running in desktop (offline mode).
I am using MSAccess 2007 as my database file and trying to write code in vb.net.
I used to write the code vb6 an usually had global variables for storing database connection and executing every query from that.
I am trying to upgrade myself from vb6 to vb.net.
do i need to read some more simple starter books also?
In .NET, talking to a database is handled with ADO.NET, which uses something called "connection pooling". The connection pool is basically a collection of open connections to your database that ADO.NET manages for you. In your code, when you create and open a Connection object, ADO.NET first looks in the connection pool to see if it already has an open connection to your data source, and if it finds one it uses that (instead of actually creating and opening a new connection). When you close your connection, ADO.NET does not really close it, but instead returns it to the connection pool.
Therefore, you do not need (and in face do not want) to maintain open connection objects inside your application (in a global variable or anywhere). The correct approach with data access in ADO.NET is to create and Open a Connection object, do whatever you need to do with the database, and then Close and Dispose your Connection.
Store the connection string in the config file (in the solution explorer, open the My Project folder and doubleclick on Settings.settings).
I'd suggest that you create one or more classes to contain your database code and let those classes convert between the database data and your application objects, most VB6 projects I saw had the GUI hard linked to the DB which can make future maintenance or new features very difficult and limits the possiblity of code reuse.
If you've got VB6 experience I'd thought that you could probably start trying to create the application right away but you should definitely read either a good book or good articles about it at the same time so that you pick up things like that you need to Dispose of your database objects after user etc.
It's probably a good idea to get a book, a lot has changed since VB6.
Also consider using a more robust db, like SQL compact or SQLite. It will allow you you use the Entity Framework which will make writing your app a whole lot easier.