Solved

How do I stage a piecemail switch over from Access to .NET solution? How to make a "seemless" user interface bridging an .mdb and a .NET program?

Posted on 2004-10-07
6
165 Views
Last Modified: 2010-04-23
I have a rather intricate database application using Access with VBA doing most of the dirty work. This application goes through regular revisions and has functionality added to it every month or so.

I would really like to start using Visual Basic .NET instead of tyring to cajole Access with VBA, but I can't justify the time needed to redesign all the forms and port the VBA code to VB .NET.

What are some strategies I can use to introduce a "phased" approach. For instance, every new form that is required I would like to build using .NET but still seem like it is "integrated" into the Access program. And likewise once the majority of forms are in .NET programs, I would like to be able to launch and run the remaining forms from Access from "within" my .NET solution.

Is it possible for instance to launch external applications from Access, and launch Access forms from with a .NET solution, so that I can offer the user a "seemless" environment even though I am using two different programs. Or in otherwords, how can I present the appearance of a signle program, when some pieces are in a network accessible Access .mdb file and others are in a compiled .Net executable?

Thanks for any ideas and suggestions!
0
Comment
Question by:majnun
  • 3
  • 2
6 Comments
 

Author Comment

by:majnun
ID: 12254047
For clarification, I don't need the access forms and the .net forms to "talk to each other" directly, they can "communicate" by modifying the underlying mdb database files.
0
 
LVL 2

Accepted Solution

by:
UncleMidriff earned 500 total points
ID: 12254406
Hmm.  This is an interesting question.  I can't say that I have ever done anything like this before, but just off the top of my head, here is probably what I would do:

I would create a sort of starting point form in VB.NET, with different buttons or menu items leading to whatever forms the users need.  If you have a particular form in VB .NET already, great, just show it like normal.  If you haven't ported the form yet, then you could open an instance of your Access .mdb programtically.  I'm not all that sure how to do it in .NET, but what I am thinking of is something similar to Shell function used in VB6.  I know VB .NET has that functionality and more, but since I have used it no more than one time, I can't really remember the specific syntax.

Anyway...I understand that the user would still have to deal with two open windows now instead of just one, but at least they wouldn't have to go hunting for the .mdb file to get to the yet-to-be ported form.

You could possibly break your Access application into separate .mdb files, each containing only one form from the original .mdb and all of them modifying tables in a central .mdb file.

Here's how I am envisioning each approach working:

Approach 1:  The user wants to enter airplane data into the database.  She opens the VB.NET application and from it is presented several options, one of which is "Enter Aircraft Data."  She clicks that button, and since the VB.NET version of the form has yet to be created, an instance of Access is launched.  Then user then navigates to the appropriate aircraft data entry form, enters the data, and then closes Access.

Approach 2:  The user wants to enter airplane data into the database.  She opens the VB.NET application and from it is presented several options, one of which is "Enter Aircraft Data."  She clicks that button, and since the VB.NET version of the form has yet to be created, an instance of the .mdb file containing the Aicraft data entry form is launched.  The use then enters the data, and then closes Access.

Still another (and probably less hairbrained) idea whould be to log the user's choice to a text file from the initial VB.NET form, and then open the Access application.  If you modfied the Access application to look for that text file upon opening to read her choice, it could then open the appropriate form for her.

If these ideas are stupid, just remember that I was just freestylin' it.  I haven't really thought the problem through, and these ideas are the first to pop up in my head.  If my suggestions are entirely inadequate, I give you permission to call me a stupid moron. :)
0
 
LVL 2

Expert Comment

by:UncleMidriff
ID: 12452358
Whatever you all decide is fine with me.
0
 

Author Comment

by:majnun
ID: 12454061
I was hoping for more different approaches... what UncleMidriff was talking about pretty much the same thing i was thinking... i was hoping to find someone who actually did something like this and could give me some practical advice... though I am glad someone else thinks about solving the problem the same as i thought too.

But if it's time to close the thread, no problem... i'm planning on launching access from within my VB project, and if i can't figure out how to open particular forms from VB .NET program, i'll do as UncleMidriff suggests and split all the forms into seperate mdb files with the "open this form on load" settings for each one.

Thanks for your ideas, and no your not a moron (or if you are then I am one too, since i had similar ideas myself).
0
 
LVL 2

Expert Comment

by:UncleMidriff
ID: 12455050
Hey, thanks for the points.

I think recording the user's choice of form in some way so as to be able to pass that choice to Access would be the best route, rather than breaking the forms into separate .mdb files.  Like if the user choose FormA from the VB .NET program, it would write "FormA" to a text file and then open the Access .mdb file.  The Access .mdb file could then look at the text file, see that the user chose FormA, and then launch that form.

I mentioned this passing in my first post, but I think it bears repeating as it would seem to be much less of a hassle to deal with 1 VB .NET program, 1 Access file, and 1 text file rather than 1 VB .NET program and 15 or so separate .mdb files.

Still though, I would be really surprised if there was not a way to get a VB .NET program to talk directly with an Access VBA program; I refuse to believe that you are the first person who has ever needed to do this :)  I'll let you know if I stumble across anything, and since I work with VB .NET and a lot of old VB 6 and VBA code as well, I would appreciate it if you would do the same for me/others reading this thread.

Good luck!
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Suggested Solutions

This tutorial demonstrates one way to create an application that runs without any Forms but still has a GUI presence via an Icon in the System Tray. The magic lies in Inheriting from the ApplicationContext Class and passing that to Application.Ru…
Since .Net 2.0, Visual Basic has made it easy to create a splash screen and set it via the "Splash Screen" drop down in the Project Properties.  A splash screen set in this manner is automatically created, displayed and closed by the framework itsel…
Internet Business Fax to Email Made Easy - With eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, fr…
You have products, that come in variants and want to set different prices for them? Watch this micro tutorial that describes how to configure prices for Magento super attributes. Assigning simple products to configurable: We assigned simple products…

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now