I’m currently rewriting our company’s database app, which is an Access-VBA frontend for a SQL Server (Express) backend.
I’ve been managing the application for 4 years or so now and when I started here it was a single *.MDB-file on a network share (which got corrupt on a weekly basis).
Since then I changed the DB to a multi-user *.MDE, later I migrated the data to a SQL Express Server as an *.ADE.
Since then the application runs smoothly and is very reliable.
But, of course there are some drawbacks using Access (no source control, dependent on Office version, etc etc), So I suggested to my boss to rewrite the frontend in C# & WPF.
I did a bit of Java and C++ a few years ago, but thats it. Now I’ve been working on this project for 3 months or so and the going is very tough. Just for such simple tasks as filling a combobox I have to search the net and read a lot of stuff.
I really want to learn C# (and also have learned a lot of stuff since I started!) and I find this a great opportunity, but maybe I have overextended myself, starting with a real LOB application as a single, junior developer?
Picking a technology for a project because you want to learn it is always a risk. I’d also concerned about WPF. For one, it’s not a proven technology (in the same sense that Winforms is). It’s still rather new. The second is that it puts potentially problematic limits on what systems it can run on. Vista/Win7 or I think XP SP3. That may or may not be an issue.
The good rule of thumb is that you should ship early and ship often. Break off a piece of functionality and deliver that. For a time you may have the users using both apps for different tasks. You’re far better off doing that than trying to swallow the whole thing in one go.
Also, and I think you’re discovering this, complete rewrites are nearly always a mistake. It’s a lot of work for not much gain, you’re giving yourself a lot of opportunities to introduce bugs in things that already work and you lose a lot of domain knowledge (and working code).