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
167 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

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Creating an analog clock UserControl seems fairly straight forward.  It is, after all, essentially just a circle with several lines in it!  Two common approaches for rendering an analog clock typically involve either manually calculating points with…
Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
With the power of JIRA, there's an unlimited number of ways you can customize it, use it and benefit from it. With that in mind, there's bound to be things that I wasn't able to cover in this course. With this summary we'll look at some places to go…
Learn how to create flexible layouts using relative units in CSS.  New relative units added in CSS3 include vw(viewports width), vh(viewports height), vmin(minimum of viewports height and width), and vmax (maximum of viewports height and width).

920 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

14 Experts available now in Live!

Get 1:1 Help Now