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

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
Gridview selected row 9 49
Prevent call a sub/function several times when data bind to gridview 21 32
Regex validation 2 28
Access/Visual Basic Question 3 24
It’s quite interesting for me as I worked with Excel using vb.net for some time. Here are some topics which I know want to share with others whom this might help. First of all if you are working with Excel then you need to Download the Following …
Parsing a CSV file is a task that we are confronted with regularly, and although there are a vast number of means to do this, as a newbie, the field can be confusing and the tools can seem complex. A simple solution to parsing a customized CSV fi…
I've attached the XLSM Excel spreadsheet I used in the video and also text files containing the macros used below. https://filedb.experts-exchange.com/incoming/2017/03_w12/1151775/Permutations.txt https://filedb.experts-exchange.com/incoming/201…

809 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