Should I migrate to VB.net?

[303factory]

Good afternoon. Apologies if this is a topic that has been discussed before, I performed a search but did not find anything useful.

We've been developing a MSAccess front end for our database for nearly 10 years now and it has grown to many thousands of lines of code with 8 modules and nearly 100 forms/subforms, some of which are quite complex (forms with multiple continuous subforms, tabs, controls etc). It now has an SQL server back end which has improved the speed and reliability significantly but there are still many problems.

The software is a bit of a monster, it is designed to allow complex data entry and data manipulation, and tends to break easily, when coding I have to take a copy every change I make because often changing just one line will cause the application to stop loading and strange things will happen like a change in the order which code is triggered as the forms load etc.
Apart from development problems the users have to close it down and open it up at least once a day for a variety of one-off issues I cannot replicate.
It is my suspicion that I am pushing MSAccess too far and the problems relate to using an inappropriate platform.

So we're thinking of migrating to VB.net (or C#) because of the instability of the client but I want to make sure that I'm doing it for the right reasons. All we are really looking for is a more stable client that is easier to develop, we dont need any of the functionality listed in the 'reasons to use vb.net' here
http://msdn.microsoft.com/en-us/library/aa192490(office.11).aspx

So my question is, do you think my problems will be solved if I rebuild the client from scratch in a more 'professional' programming language, or is it possible the problem is only due to my application design and I would be wasting my time changing the language if I do not need any of the new functionality and I am likely to replicate the same problems in vb.net.

Any comments on the pros and cons of this migration would be much appreciated, despite working on this application for about 5 years myself I am not a talented programmer and Access is pretty much all I know.

303

 

[gemma-the-husky]

I would say you would have to programme in all the functionality of the access db manager that you take for granted, if you move to a non-dbs manager platform. Lots of time and heartache, I would have thought.

Just try building a simple form in VB to maintain one of your standard system tables, to see how easy/hard it is.

big apps are complex beasts. i would think if your app fails, its because the code needs looking at, and not because access cant do the job.

 

[ChipperT]

Rarely are these issues due to language. Legacy software tends to doom itself due to the piecemeal way it grows. While there may have been an original good design, it sounds like your application has gone far beyond that and is now out of control. My advice is to take the time and sit down, re-design the entire app from the ground up with an eye to future needs before you touch a line of code, and then build the new code in the language you are most comfortable with.

 

[boblarson]

do you think my problems will be solved if I rebuild the client from scratch in a more 'professional' programming language,

I see you are one of those who have a misconception about Access being a "professional" programming tool. Access is enterprise capable, if used in the right way. But a lot of people still look at it as a "toy" so-to-speak. The correct way to view it is that it is as professional as any other tool when used by professionals. The other thing is that it is a rapid application development tool. It can pull things off that would take months for another programming tool to do.

...or is it possible the problem is only due to my application design and I would be wasting my time changing the language if I do not need any of the new functionality and I am likely to replicate the same problems in vb.net.

Yes, that would be the case. The program is only as good as it is designed and produced. There might be some valid reasons to moving to another programming tool in order to build the frontend application. The question is, are you thinking of doing so for the right reasons. Now if you are suffering from corruption and things like that - yes, Access is more prone to that. So that may be one reason to think about moving. But realize that you would need to have a good .NET programmer to design the frontend well and program it and if you are going to be doing this. And you should realize that normally doing the same thing in .NET as in Access, the time frame is something like 3X to 10X the time necessary to build. It is that Access provides so many things to you (bound forms, report writer, etc.) that people forget that you'll end up having to code for a lot of things you normally take for granted.

Anyway just my thoughts.

 

[DJkarl]

I develop most of my new apps in .NET and still use Access as a back-end data source. There is a bit more dev time depending on the app, but once you build a respectable re-useable library of common functions the dev time on a .NET solution is close to what I can do directly in Access (though still slightly longer). The one exception to this is Reporting, I can still create Access reports much faster than I can in the .NET equivalent (something like Crystal Reports).

Where .NET really shines IMO is the ability to multi-thread the UI. In Access if you have a long running query or report your screen would go white/blank and you can do nothing until it's done, in .NET I can run those types of processes as background threads which leaves the UI available if they want to do something else, or simply to monitor the progress.

 

[dfenton]

To me, developing in .NET and using Jet/ACE as a back end is turning everything upside down -- you lose the RAD capabilities of Access while using a fine, but not terribly scalable back end.