All,

This is a open ended question but I am wanting to know where to begin learning to write a database with GUI. The software that is used where I work and happens to be the number one software in our industry is very lacking. I am what I would consider an above average Access user and have created many databases with Access. However, I understand sql I have never created an sql database. My first goal is to learn to use mysql and create a database. The question is, from there what is the best direction to take to create the GUI to go with this?

I know this is vague, even n00bish.

Any direction, comments...suggestions would be greatly appreciated.

Edit: I guess I am asking, is Visual Basic, java, php, c++....anyone better than the other or easier to learn? This would be a user base of 25-100 users.

If you consider yourself an above average Access developer, then I presume you have extensive experience coding modules, event procedures, and custom functions in VB for applications to enhance your Access database applications. So I would think that coding your front-end in VB (.net) would present the shortest learning curve.
If you don't haven't done much VB coding in your Access applications, then you are in over your head.

I know. I feel that way also.

if you have been designing stuff in Access, then unless you are talking to say a dBase, or some other legacy data store, or possibly Excel /word then you have almost certainly been designing SQL databases.

as to the correct choice of weapon system (php/MySQL, Access/JET or MySQl or SQL server) that depends...
it depends on what the aim of the operation is.. is it a business requirement that is dictated by a customer, is it a 'for instance' training exercise for you, is it cost driven.
how many concurrent users do you expec to use the app.

We based GUI is pretty limited, although with the advent of AJAX you can get a more traditional style UI if you so wish

if its cost driven then its very very hard to beat something PHP, especially if you are using MySQL. Mind you having dabble din Ruby on Rails that to seems pretty nifty.

if its a scaleable business solution that cannot run on a web system then virtually any of the .NET technologies are appropriate

if its a package to be sold to someone then .NET is almost certainly a requirement

if its a training / CV building exercise then .NET is probably the best route.

Personally I find PHP pretty easy to develop for..., for web work its plenty powerful & flexible enough, there are a lot of classes and libraries out there to do what you want and it isn't going to cost a great deal. the downside is debugging can be a pain, especially if you are going for web 2 and/or integrating Javascript into your pages.. even with the Eclipse IDE. You are not going to get anywhere near the level of breakpoints and debugging capability that comes so easily with VBA.

If you are up to speed then anything VB related (VB,VB.net, ASP, ASP.NET....mebbe even C#) will be a shallower learning curve.... if you haven't used C or C++ before then personally Id avoid it like the plague. Many developers swear by it, Im in the camp that swears at it.

Java is supposed to be the coming language.. it hasn't knocked C or VB off its perch yet, and its been doing the rounds for a while.

Thanks first for the replies.

To be more specific, I work in a Industrial repair facility. There are over 2000 of these shops in 50 countries (or so the association states) and the majority of them, at least in the states, use the same software to run the business.

The software controls:
-Shop
-New Sales
-Inventory
-Employees
-Accounting

I am not afraid of the database side of this. It's the UI that I can't decide where to start. I was thinking php or xul.

I am over my head. But everyone has to start somewhere and I will be pissed at myself one day for not trying.

Time to start educating myself.

Were I in your position, I would create my database in MSSQL, which has a very functional SQL syntax along with the ability to create versatile stored procedures, views, and user-defined functions. I would put as much business logic as possible into procedures, functions, and constraints on the database side, so that I could limit my interface to simply calling stored procedures and displaying the results. This gives the greatest flexibility for the user interface. You could start with a UI based on an MS Access Data Project, which would allow you to get something out right away as well as proof your database design. Then, you could write a more robust .NET interface calling the same procedures.

Thanks blindman. Gives me something to start with.