Going from VBA to Visual Basic

[Never Hide]

I was just wondering how difficult it would be to transfer the form I've created in Access-vba- to a Windows Form Application in Visual Studio. I've created a form for a database that we have in our company that calculates for you the cost for a chosen route. It'll be used by our tech support employees to calculate te cost of a route when they have to go out,to customers. I've done that in Access and I'd like to take it to visual studio so I can make that little form "more portable".
What are your thoughts?


P.S. :I'm using MS Access 2003 and Visual Studio 2010 Ultimate

 

[Pat Hartman]

There is no more VB. It is now VB.Net which is very different from VBA. You'll need to rewrite your code. It will be similar but you'll need more of it.

with the last two versions of Access - 2007 and 2010, the runtime engine has been free. That allows you to create a A2010 app (you probably can't get the A2007 runtime anymore) and distribute it with the runtime engine so your users won't need the full retail copy of Access. It is still more of a pain to distribute than WinForms but at least you don't need to shell out for additional software. When you use the runtime to run your app, you need to make sure that you have adequate error trapping and that you have provided forms for all your interface needs. The user will not be able to get to tables/queries or any other objects. All he will see are the forms and reports you display for him. To see how your app would look under runtime control, create a shortcut to launch your app and add the /Runtime switch at the end. This tells Access to pretend to be the runtime engine.

I see that you are developing in A2003. I know everyone complained about the interface changes with A2007 but Microsoft is not changing back so it's time to move into the current decade. There actually are some useful new features in A2010. You can probably continue with A2003 if you must and still use the A2010 runtime. Download the runtime from the Microsoft download site and test it.

 

[gemma-the-husky]

I looked at VB.net. As Pat says, there IS a learning curve. It is different to VbA. The library usage is different, the event model is slightly different. Simple things in VBA need reconsidering in vb.

one thing I could not follow - and I think I need more work on it, as that somehow linked data set actions are not updated immediately in vb - they seemd to write to a local copy of the bound data - which made multi-user applications awkward to manipulate.

probably me, I think.

 

[Pat Hartman]

Me too. Access was always intuitive to me. Even in the early days when I went from COBOL/CICS/IMS to the Access client/server model. Having my code scattered all over creation was a bit of a hurdle for me but the GUI and the object model always just made sense. I can't say the same for Visual Studio or VB.Net. In fact, they make me feel downright stupid.

 

[spikepl]

You need to be specific as to what the requirement would be before talking solutions, because that is not apparent from your post.

A Form in Access is not functionally equivalent to a form in VB.NET, because an Access form is more or less married to the Access-engine which runs locally (with some few exceptions). A VB.NET form can be married to anything you like, provided there is a connection to it. To create a local Access-engine based app using VB.NET is a painful way to get not much more than a local Access runtime installation can do.

For remote connection there is always ASP.NET, so nothing needs to be installed locally. But that has an even steeper learning curve because of the server-client roundtrips which is a concept rather foreign to developers used to local applications.

 

[Pat Hartman]

because an Access form is more or less married to the Access-engine which runs locally (with some few exceptions)

Access is not married to Jet/ACE. Access works with any relational database that offers an ODBC interface. In that respect it is no different fro VB.Net, ASP.Net, C# or any other "real" language. Access has one real advantage over those other environments, it can swap back ends on a dime thereby living up to its name. Try that with a different development tool.

 

[Never Hide]

Wow! I guess I took this whole "more mobile" concept a bit lighter than I should have
I've got a lot more thinking to do -as it seems- before I move on to further development

Thank you all for your input,it really was enlightening

 

[Galaxiom]

For functions and subs not attached to forms and reports, VBA code pasted into Visual Studio is reasonably well understood by VB.NET as a Console Project.

The first thing it does is automatically drop the Set keyword which is not used in VB.NET because every variable is an object. Even Null is an object. Realising this fundamental difference is vital to understanding the nature of VB.NET.

Visual Studio then highlights the syntax errors, suggests what is wrong with the code and suggests replacments. Some of the functions used in VBA need to be replaced with methods of the object variables.

Even Visual Studio 2010 Express (the free version) is a world more advanced as an editor than the VBA version with really intelligent highlighting and all that prompting help instead of what amounts to little more than "nah" in the VBE.

It is of course more complex than my description but the learning curve is not too bad. It gets more complicated when you have to design the forms but I would suggest anyone wanting to learn should start with a simple console application.

 

[Never Hide]

Well my form is pretty simple actually,it only has 3 combo boxes, 1 list box ,5 text boxes and 5 buttons.
Our company has 2 different shops in 2 different cities and a tech support guy can go to an other city for customer support from either of the company's "base" city.We have in the database the distance for every city/village,in which we offer service, from both "base" cities. What you do with this form is you select your starting point and then you select a destination and you press the add button,and the selected destination is added to a temp table and is displayed in the list box. You can add more destination cities to add them and this way you create the route that your going to have for the day. Then using inputed parameters from the other text boxes (number of customers in each stop,fuel cost etc) the cost for each customer in every stop is culculated.
Since everything is working great I thought it'd be easier to distribute-and also use- this form if I created a "Windows Form Application" in visual studio instead of having to open the whole Access everytime you want to use it.