wanting to move up from ms access, thinking .net? visual studio?

Question

So I wrote a project-management program for a small business using Microsoft Access 2007.

Now they've requested lots of additional features (timekeeping, privileged data tiers ...)

I personally use Linux, but the whole office uses Windows.

I'm relatively new to programming but like to teach myself using projects like this.

I'm right on the edge on this -- I can't really tell what the path of least resistance here is: do I stay in access + VBA and teach myself a dying, annoying language -- while struggling against all the limitations of Access? Or do I move to something else?

Python seems simple enough ... Whatever I use, i need to be able to offer a GUI.

screenshot so you can get the jist: http://img707.imageshack.us/img707/9360/screenshot1fi.jpg

http://img707.imageshack.us/img707/7338/screenshotmh.jpg

-- notes: current access project uses seperate frontend-backend for multiuser sharing over a LAN

cross compatibility with linux is not that important to me, i've been using virtualbox for a while now.

--UPDATE-- my wanderings have convinced me that i should proceed in IronPython -- however -- as I try to install the suite in both XP and 7, and fail ... I wonder if this also is something outdated ... most importantly, iv'e been reading up on it and I LOVE PYTHON 3 -- but i need to offer a GUI for Windows not sure where to start with that (including which IDE to use, etc)

Answer 1

In an environment like that, you can't go wrong with VB/C#. Try the various VS Express editions.

If you want something that will translate to Linux a little more, Python and just about any cross-platform GUI framework(QT, or wxpython) would work.

EDIT: Then there's the database. I would probably suggest sqlite if you want to learn something cross platform. Sticking in the Microsoft world, there's SQL server compact.

In a business environment like that, a .NET app is probably more maintainable(after you're gone, etc) then anything that's not completely Microsoft.

Answer 2

As long as the clients don't share a database, a .NET WPF/WinForms app w/ an embedded DB sounds like it would work just fine.

You could probably even develop something that works on both Windows PCs and your Linux machine using Mono (you'd be stuck with a subset of WinForms...but for a simple business app, there's really nothing wrong with that).

Answer 3

Have you thought about Appcelerator Titanium or something similar? You create a rich GUI using web techniques (HTML, CSS, javascript and or python) and compile that to a desktop application.

The advantage would be that you can develop on Linux, and only do the final testing & deployment on Windows.

That said, writing production software as a beginner is not easy. Especially handling errors can be difficult. Be smart and think about "What can go wrong when the user does this" all the way, and validate input.

Answer 4

I would say web app (C#) with SQL Express on the back end - but this is just me

Answer 5

WPF has a pretty steep learning curve, especially coming from Access. WinForms would be a simpler path, but it's still a leap from Access. However, both WPF and WinForms have drag-and-drop form construction, and assuming you learn enough VB.NET to convert the VBA business logic, you're more than halfway there. :)

If you implement your project in WPF, you can make it Silverlight-enabled, but that's a whole 'nother can of worms.

Answer 6

MS Access is a desktop database application. One step up is most likely SQL Server Compact Edition (SQLCE), which operates as part of your application (as opposed to SQL Server Express or higher, which run as system services). I've used SQLCE with a great deal of success in a few applications, and Microsoft is using it in Visual Studio 2010 for the new Visual C++ IntelliSense cache because it's lightweight and performs great.

Despite what I've read on some sources, SQLCE doesn't cooperate well with the Entity Framework. It does however work great with LINQ-to-SQL and the corresponding designer. That said, my personal recommendation is you consider combining the following as your replacement:

• Data: SQL Server Compact Edition
• Data/Code: LINQ-to-SQL
• Programming language: C#
• Application framework: WPF
  • Personal note: WPF does have a learning curve, but it's primarily difficult for people who've worked with other frameworks (MFC, WinForms, etc.) for a long time. Pick up a good reference and you'll be productive in no time, plus you'll be skilled in a technology that people are moving towards instead of away.

Answer 7

VB and C# are certainly similar to Access, and would be good if you are looking to not move too far away.

Python is brilliant but nothing like Access. It is simply a programming language that happens to have good db libraries. The GUI libraries look pretty good as well though I have never used them. GUI design will be harder in python than C#/VB. Python is free and may be worth just experimenting with ie. build a GUI,connect to an SQLite database. You would probably get a good indication of the feasibility of using python for your purposes.

Dont stay exclusively with Access. Access is pretty good for small applications and you can do some stuff really quickly. On the other hand VBA is brutal and is severely limiting. Try both C# and python if you can.

Answer 8

I said this in a comment, but I'll repeat it as an answer:

If you look at the future of Access, it's bright. MS is investing a lot in it. Access 2010 in conjunction with Sharepoint 2010 offers some pretty amazing benefits, and you do it all without any VBA (instead you use the new, powerful macros, which have variables, branching and error trapping). You can do this with client Access and no Sharepoint, or you can publish it to Sharepoint and the app runs in the web browser.

My surmise is that one of two things are going to happen in regard to the programming language in Access in the timeframe of the 2-3 Access versions after 2010:

1. VBA remains supported and all the work goes into macros. Eventually, macros become the preferred method for all programming in Access, with VBA eventually deprecated and finally eliminated. Because by that point macros are so versatile and robust, not programming language will replace VBA.

2. the same scenario, except that .NET is phased in as a replacement for VBA.

I would hope for #2, but it depends entirely on Microsoft's view of what Access is, i.e., primarily and end-user tool with upward extensibility (#1) or both an end-user tool and a versatile development tool with unlimited extensibility (#2).

My point is that you can stay with Access, avoid VBA for now (if you really hate it), and probably end up with a workable, stable app.

However, my reservations about macros are very strong, in that I find them very difficult to maintain because of their standalone nature. VBA code is pretty easy to navigate and understand, because it's compiled and because there's a full-featured IDE. Macros are much more compartmentalized and difficult to trace interrelationships between them and the objects they are used in. Add in the embedded macros added in A2007 and it gets even more complicated. I don't know if the Access team is addressing this or not, but for me it's a real step backward in terms of manageability, particularly if the beefing up of macros ends up causing VBA to be deprecated and then not replaced with a correspondingly powerful programming language with a good IDE.

Last of all, I've said nothing about the database engine, since Access is completely agnostic on this regard, able to use Jet/ACE to start with and then to upsize to the engine of your choice. It's a non-issue, seems to me, since your options are wide open when using Access as your front end.

Answer 9

Based on your criteria, I would use PyGtk and Glade. Gtk is well supported on Windows and Linux, and I've gotten more done in less time with Python and GTK, than with any other language/toolkit combination.

If you are willing to rethink doing it on the web, have a look at ExtJS, which provides a lot of desktop like web controls, and they have a GUI builder.

For the database I would go with Postgresql, or SQLite. Be aware that SQLite has some severe limitations when it comes to concurrency, which might be a problem depending on your application design, and the number of users.

Answer 10

If it's only smallish, internal apps you're working on, take a look at Visual WebGUI - you get a very VB6-like development environment for web apps. I would not recommend it for large and/or public apps though.