Front-End Back-End what to use?

[Matt_Hirst]

Have an existing application, not written by me and there is no documentation, that requires major redevelopment for use in a multi-user environment, currently its a stand alone application, it will be accessed via LAN and WAN with max number of potential number of users being 10 - 15. Max number of records approx 10,000.

Now the existing application is a VB6 front-end and MS Access backend.

The new IT system the application is to be installed upon has known issues with using MS Access as a backend, I believe there are timing issues when using Access as a backend where connections timeout, so the new system can use either Oracle or MS SQL Server and it is upto me to decide on the front-end.

So what would you guys use as the front-end / back-end? Requirements are that whatever is used has to be fairly easy to pick up (work will send me on a course if needs be), I come from an Access background and dabbled with VB.NET AND VB 4 - 6, support multi users and finally be a good thing to add to my CV (well I might as well get something out of it).

Specs a bit vague but hey this is the hand I have been dealt.

regards,

Matt

P.S. Forgot to add if you could point me in the direction of some online learning for whatever your suggestions are it would be appreciated.

 

[kwerk]

Iron Speed Designer.

 

[Pho]

What does it actually do - only generally if you don't want to give full details? Depending on how the application is used might affect what language you use to create it.

If it has to be desktop then C# and MSSQL would be my choice, it sounds like you don't need cross-browser support anyway if it was written in access and VB6.

If it's something which would work hapily in a browser - i.e. simple customer and order management - then ASP.NET (you can use C# or VB) and MSSQL or PHP and MSSQL would work fine.

If you write all your database access as functions and stored procedures or create a shared DLL for your 'engine' you can even create a desktop and web application for maximum usefulness without too much effort .

 

[Matt_Hirst]

What does it do - well it's a basic scoring system, performance monitoring database. Guess you could say you record people against certain tasks and can then compare them - sorry I have to be quite vague on this.

regards,

Matt

 

[Pho]

Well it sounds like a web application would be much more suited to this then, and far easier to maintain - just stick it on a server and give people a URL and login details rather than having to worry about installations .

Have fun : http://www.asp.net/LEARN/videos/

 

[topbanana]

Is this application important to the business? I don't mean to offend, but wouldn't they be better getting an experienced contractor in who could mentor you through the project?

If you're using MS stuff, the back-end should be SQL Server probably.

You haven't given enough info for the front end. It would probably be a choice between WPF for a rich client and ASP.Net MVC for a web client.

 

[Matt_Hirst]

Have been having a look at SQL server and php to act as front end, both seem quite straight forward to use.

Topbanana, no its not a business critical app, but is important.

regards,


Matt

 

[Matt_Hirst]

We now have integration problems so it looks like this app will have to run on standalone laptops until the networkm integration is sorted out.

The main thrust of the existing application is a database backend and the beauty of the existing app is that we can create a database and transfer an empty copy with the front-end app and it'll work.

A rather stupid question:

With SQL server would we have to have SQL Server installed on each of the stand alone laptops?

Obviously the cost side of this would be rather huge, compared with the existing application. What other options could we use in this case?

regards,

Matt Hirst

 

[Matt_Hirst]

Just looking at SQL Server - what restrictions are placed on developing a database in SQL Server express 2008?

regards,

Matt

 

[topbanana]

You can use SQL Server Express on the client machines, limitations are on the MS website.

It sounds like the database synchronisation be only one-one (server -> clients). This isn't so hard, but it's a pain.

If each user can update the local database and then have the changes propagate to the central server, you've just made your solution much more complicated!

 

[Matt_Hirst]

Each user would have there own database and front-end and then email the data back to a central database.

Yes I can see a faff with regards data sychronisation at the central point but each remote user would see no change to what they do with the existing set-up.

Or am I missing something?

regards,

matt

 

[topbanana]

I don't know enough about your application. What happens if two different people change the same bit of data, and you have to roll up the changes centrally?

 

[lokkers]

Each user would have there own database and front-end and then email the data back to a central database.

Yes I can see a faff with regards data sychronisation at the central point but each remote user would see no change to what they do with the existing set-up.

Or am I missing something?

regards,

matt

My god, that's screaming out for a web application. I would strongly recommend something like that rather then trying to synchronise data. Believe me, it can be an absolute nightmare.

 

[Dolph]

Each user would have there own database and front-end and then email the data back to a central database.

Yes I can see a faff with regards data sychronisation at the central point but each remote user would see no change to what they do with the existing set-up.

Or am I missing something?

regards,

matt

Please, please, please don't do this....

Either serve the back end centrally and connect using a custom frontend (written in VB or similar), or move to a web/intranet based setup.

Really bad design decisions made in the past are not a good reason to carry on with them in the future if you have to do a complete rewrite anyway....

 

[Matt_Hirst]

Guys, the problem is restrictions on the IT side of things which we have no control over - lack of software on the network, no databases will be available to utilise on the network for at least 1 year.

Topbanana, whilst the data held will be the essentially the same it will only be relevant to the remote site so therefore all unique to that site.

I can see what the issues are, but am having to make the best of a very bad job, but still have to come up with a solution of some sorts no matter how lame it may be.

regards,

Matt

 

[lokkers]

Guys, the problem is restrictions on the IT side of things which we have no control over - lack of software on the network, no databases will be available to utilise on the network for at least 1 year.

Why? If the system is business critical then there should be ways through this. Presumably your network is controlled by a third party? If so, do they actually want your business in future?!

If the data is standalone (I.e you will never need to merge it/synchronise it) then MSSQL Express on each laptop, with a Winforms application talking to it. If the data needs to be synchronised centrally, then for the love of all things holy use one central database and have all clients speak to that, either using citrix/WTS (using winforms) or a web application.

Personally, I'd go with a web app. You don't need to expose anything over the local network, you just need a webserver.

 

[topbanana]

You can still use a web-app even if you have to cache data 'offline'. Google Gears would give you SQLite on each machine.

As others have said, you really don't want to go down this road if you can avoid it. Presumably your guys can get an internet connection out in the field? There's no reason why you can't host your app externally if your internal network isn't up to it.