.net – How to prevent to open a MS Access Database while reading data from forms

ms-accessvb.net

To count Activex controls from MS-Access forms using vb.net I am using the connection as follws..

oDBEngine = oAccess.DBEngine
oDB = oDBEngine.OpenDatabase(Name:=strFullFileName, Options:=False, ReadOnly:=False, Connect:="")

and Openning the forms in Design mode, as there is a user input prompt form which prevents us to run the application further if we open it in Default view.

oAccess.DoCmd.OpenForm(FormName:=objForms.Name, View:=AcFormView.acDesign)

Now the problem is:

The DataBase gets opens and along with that all the forms open up while running the application. Is there anyway we just prevent to open the database and forms, while reading the forms.

Thank you.

Best Answer

Sounds like an unsplit application (tables and forms/etc. in a single MDB file), and that it's being shared by multiple users. This is a disastrous scenario. See Splitting your Microsoft Access MDB into a front end and back end for all the details.

Once it's split, you'd work on an individual copy and then distribute updates to users. The point is that since version 2000 the design of an Access MDB (as opposed to the data) cannot be edited while it's open by any users.

Related Solutions

R – How to structure VB.NET Windows Forms applications

I had great success with this Passive Screen pattern.

In my opinion, the big problem of the traditional MVC architecture is that people stuff way too much into the form classes. This increases the amount of manual testing you have to do.

The more automated testing you can do after you compile, the more bugs you will catch at your desk. In a complex application, the side effects from even minor changes occur all too often.

The trick to solving this is making a controller assembly that the form assembly (or EXE) references. Every form has a corresponding class in the assembly. Clicking a button will call ThisForm.ThisButton(<args>) which will then fire objects lower in your framework. Each form implements an interface so that, if the controller class needs additional information from the form, it has a interface to retrieve it.

Then for your unit testing you simulate an operator performing complex operations by implementing dummy classes to fire events and feed information to the controller classes. The controller classes don't know any different as the dummy classes implement all the expected interfaces.

There is an important exception and that is for trivial dialogs. For dialogs that have a few check boxes I feel this organization is overkill. I use the command pattern a lot. So in the assembly where I define the Command objects, I put the SIMPLE dialog associated with that command. How simple a dialog has to be to get this treatment is up to you.

I like to structure my applications as follows.

Utility - This is an assembly that has stuff I use all the time - Math functions, file function, etc.
Objects - This has the specific objects I am using for this application.
UIFramework - This defines all form and controller interfaces.
Commands - This has all the Command objects that manipulate my application objects.
UI - Objects that implement the controller interfaces
EXE - Forms that implement the form interface and calls the controller objects.

.net – How to suppress a prompt window to continue further

Can't you open your forms in design mode:

docmd.openForm "myFormName", acDesign

You'll then be able to freely browse the objects in the form and identify your activeX controls.

Best Answer

Related Solutions

R – How to structure VB.NET Windows Forms applications

.net – How to suppress a prompt window to continue further

Related Topic