Moving from Access VBA to Visual Studio

Hello everyone,

this is my first post here.
I've developed a form in access to use in the company I work for to calculate the cost for a route taken by the tech support guys. Let me elaborate a little to make things a bit clear.
We have 2 shops in 2 cities and we use either of them as "starting point" and we offer tech support to our customers in other cities. So in this form you select the city you are going to(you can select more than just 1 city) and the number of customers and then it calculates the cost for the route. It all works as intended. Now because it's a bit annoying having to open the whole access every time just to use the form, I'd like to make a Windows Form Application so it'd be easy to distribute around the company and also faster to use.

Do you think this is the right path to follow or should I use somthing else from Visual Studio? Could someone direct me to the correct path plz? :D

I've used MS Access 2003(that's what my company has) and I've got Visual Studio 2010

P.S. Last time I used Visual Studio was with VS 2008 and I'm @ a beginner's level :o

I would say that it IS the right solution. After all, you could eventually expand the scope a bit where there is a single database, and everybody uses that, regardless of their location. If you go there, you won't want to be using Access at all, based on what you said. A stand alone app could be written such that it targets whatever database. Access could be used for now, because that is what you have, but if you build it right, you could switch to SQL Server, MySQL, or some other DB, with minimal changes (nothing but the connection string, if you really wanted, though you might be less strict than that).

Of course, VBA is quite similar to VB6, and therefore is not all that similar to .NET, but since you have worked with VS2008, you already know that, to some extent. Still, the only reason you would consider VB6 is because of your familiarity with the language, which is really not a good enough reason, since Access vs. a Windows Forms app is already a fairly significant change.

I would say that you are ideally situated, and on the right track.

Thanks a lot Shaggy:D:D
Do you know where i can find a few good tutorials on vb.net to get me started with it?:bigyello:

this is probably as good place as any: http://www.vbforums.com/showthread.php?t=337051 --- that's our very own Database Tutorial and FAQ section... it's got some good advise and habits to follow.

-tg

Thanks a lot techgnome

I'll jump right on it:D

VB6 isn't the best choice if you don't already use it.

However .Net isn't necessarily the way to go nor the only game in town. You might consider Java, which maintains popularity and has better tooling than in the past as well as being a cross-platform alternative.

Quote:

---

Originally Posted by dilettante

VB6 isn't the best choice if you don't already use it.

However .Net isn't necessarily the way to go nor the only game in town. You might consider Java, which maintains popularity and has better tooling than in the past as well as being a cross-platform alternative.

---

Isn't VBA similar to VB? Thus VB would be the better option to convert to rather than trying to convert the code to Java?

I don't think this was as much about converting existing VBA code as it was moving away from Office VBA hosts and writing actual programs.

However my real point is that acquiring VB6 legitimately is hard now, and it has its own learning curve (there is a lot more to a programming language today than just the syntax). So with so little to lose moving elsewhere shouldn't be a barrier, and there are lots of easy-to-get-started-with "elsewheres" available.

I'd certainly argue against VB6 for all the reasons that Dilettante is pointing at - essentially, why learn a dead (or at least very sickly) language?

I also agree that VB.Net isn't the only alternative. Java, C#, VB.Net... basically any language that supports a visual designer and database connectivity are valid options. It doesn't even need to be windows form based, you could consider a web technology if you thought it would be suitable.

I think I'd probably aim at VB.Net because it's probably the closest current language to VBA but that's not the only consideration. Do you want it to be cross platform? If so Java is obviously a good choice because it was designed with that in mind. Do you just want something that'll be quick to develop? In that case VB.Net is probably the easiest to learn (though not necessarily "easy"). Are you a bit of a masochist who wants to set themselves a real challenge? If so C or C++ will certainly provide plenty of headaches for you to learn from and let you start seeing under the lid of what's going on.

I think moving to a separate client is definitely the way to go but the choice of language is alot more woolly. None are 100% right, very few are 100% wrong. They just have differnet strengths and weaknesses.

.NET was designed with cross platform in mind, too, it just hasn't turned out that way....but Java wasn't so platform agnostic, either.

Also, C/C++ would only be a little masochistic. If you REALLY want to be a masochist, write the thing in ASM.

God...my only regret in the world of programming was not learning ASM. I regret that every day :( Such a powerful and interesting language.

Uhhhh....yeah. Write a lot of device drivers, do we?

I learned ASM some 20+ years ago... and I've never used it again since, except for a one-week stint in the AF during training. The only advantage I ever got out of it was how to write tight loops and conditionals that minimized long-distance jumps and that a boolean NOT expression is fast than a not equals expression. those lessons are still ingrained in me so I still use them, but now it's out of habit more than out of a need like it used to be.

-tg

Quote:

---

Originally Posted by Shaggy Hiker

Uhhhh....yeah. Write a lot of device drivers, do we?

---

Nah, never really thought about device drivers although it would be nice to learn how to write these things. I started programming way back when DOS was prevalent and ASM was quite popular as it compiled to very small EXEs which is good since you only had 640K memory to play with. Also, Mega-Hertz was yet to be ubiquitous so finding ways to get blazing performance was something of an art. I tried to learn ASM in those days but I guess my young brain couldn't really handle it as there are no abstractions when dealing with ASM coding. I was lacking a lot and I mean a lot of relevant knowledge. I didn't know about registers or about the significance of HEX. The stack-based approach of ASM was completely alien to me as childish naivety had me expecting ASM to be similar to QBasic only with different syntax which is far from the truth. I know ASM is know longer needed in today's world but I donno, the feeling I always get when I think about it is like I left something undone...you know ? Like this is something I should know. Feels like there is this huge gap of missing know how.

I did a bunch of work in Quattro Pro macro language, which bore a real resemblance to ASM, except that the number of registers was nearly infinite (you made your own stack and heap by designating areas for each), and there were no comments. It was painful to do something large. I found that I had to stop work around noon, because, after 3-4 hours writing code, anything written after that time would be so buggy that I would make no net progress.