What language should I use?

N

noodlesoup

Newcomer
Joined
Aug 5, 2007
Messages
6
I am writing a small custom accounting software for my company.
This application will have to be accessible for 3-4 people within the local area network at the same time.

I am thinking of using ASP + Java Script + Access through IE interface to design the software.

The only condition is that the software will have to react spontaniously because those account does input number fast.

Any one has any suggestion on how and what language I should use to write this application?
 
I wouldn't have thought there would be much of a problem using any, to be honest.

If you're using JavaScript, though, you may find it easier to code using C#, than having to switch to VB... If you're already used to using ASP then the choice is really yours.

At the end of the day, speed of entry isn't really a problem. I suppose the real problem is how you design and implement the user interface.

Just as an extra here, you're more likely to find employment for C# developers than VB...


Paul.
 
mandelbrot said:
Just as an extra here, you're more likely to find employment for C# developers than VB...


Paul.
Click to expand...

This is true. Once in awhile I look at the employment classifieds, and most require C language of some sort. Unfortunately I never learned to use it(besides taking it in school way back when. Use it or loose it) and don't have the time. I just happen to goto companies that always used VB. From pro-basic to .net.
 
thanks....
I will use C# to design this program instead. I am familiar with Java. I hope it won't be too difficult pick up C#.
And the UI is already designed.

My problem now will be to learn to setup the database server, and figure out how to share the same database between few users at the same time.
 
If you can use JS then you'll have very few problems with C#. In all probability, I would think it will be the other way round - the more you learn about C# the less you'll like JS!! ;)

Access is pretty much pants! To be honest I would be tempted to recommend that the company you're working for invests in a basic copy of SQL Server, or even MySQL. You could even cheat and use MSDE, but you'd need to check out the EULA on that.

Good luck, noodle.
 
I'm not trying to steer you away from Visual Studio, although both these thoughts may make you think that. And I'm no expert on either of these, so just throwing these out as options:

1. I'm not an accountant but have Quickbooks experience. Recently I started using GnuCash, which is an open source competitor to Quickbooks. All I'm doing with it is managing incomes/expenses on a couple things I have going, and I like it so much better than Qb. That being said, read the "Recently I started using..." part; But, you may want to spend a day or two with it to see if it will min checking it out see if it will meet your needs, or how easy/difficult it is to change. There may even be templates/reports out on the web, I dunno, I haven't searched.
Here's a link: http://www.gnucash.org/

2. If GnuCash (or anyone else's apps for that matter) doesn't meet your needs, have you considered AJAX? It's not a language, but rather a technique combining Java and XML to serve your web pages. I would imagine that if Access can handle the amount of data you're wanting, you can also handle it in XML fairly easily.
About: http://en.wikipedia.org/wiki/Ajax_(programming)
Tutorial: http://www.w3schools.com/ajax/default.asp
 
I have one more question on this topic.
What's the difference between MS Access and sql?
considering the current condition, it is too much change to setup a sql within our LAN. Therefore, share folder will be the simpliest method.

Will it be possible for Access to be opened by the different users so that they can work at the same time? or do i have to go with SQL?
 
Hi noodle,


To be honest; stability, scalability, reliability, usability ... Have I missed any abilities there, anyone?...

I believe the greatest asset is the stability factor. You can have numerous people connecting to an SQL Server database, whereas, Access loses stability the more people using it. I've always found that if you have more than 5 people writing to the database at once it tends to cause problems.

The Access that comes with Microsoft Office is really a glorified editor. In practice, you can create Access databases without the editor so long as you have the MDAC extensions installed on your PC. VS.NET provides you with the tools to edit and create Access databases anyway (including MDAC), but, as I said earlier, I would use SQL Server or MSDE.

alreadyused has a good point, too - if there's already a solution out there to perform a specific task, why re-invent the wheel? Even if the application does not fully meet your needs, you could mod it to do what you need (as it's under GNU licence).

Also, AJAX is available for VS.NET, giving you further flexibility (though I believe it's called something else or works slightly differently for 2005). On top of this, you don't have to write a web app - you could write a Win32 front end (using VS.NET), which is far more simple to manipulate, and can be real time if you choose...


Paul.
 
Last edited:
Access can be used by multiple people at once but it can suffer in terms of performance and stability as the number of concurrent users grows. Access can also be problematic in terms of back up strategies as if users have left a connection open the .mdb will be locked and most file based backup solutions will fail to work correctly.

Ideally I would opt for SQL over Access every time (even SQLExpress is a lot better that Access).
 
One problem we had, also, with Access was that someone using Win2K decided to compact a multiuser database on their own PC desktop, and then returned it to the server. This actually replaced the permissions on the DB, denying access to all but the person who compacted it...

I don't know if it's getting any better, as it's a long time since I've actually used Access, but we have had so many problems that I wouldn't recommend it for any but the most basic of user applications.

PlausiblyDamp said:
Access can be used by multiple people at once
Click to expand...
Yep - as I said...
mandelbrot said:
...Access loses stability the more people using it.
Click to expand...

Paul.
 
on the access vs SQL question (assuming you're doing it yourself)...

The biggest thing I can suggest is make sure you use the n-Tier layout.

The most important part of this is you want an object to handle the communication between your database(s) and your client application. We'll call that DatabaseHandler for this post.

The reason this is important is because you expose methods in your DatabaseHandler class to your Client app to pass you information, and then DatabaseHandler determines which database to read/write from. It's sole purpose is receive input from the client, determine which database it should talk to, pass it on to that database, and vice versa.

Then the last thing you need is a class for each Database, ie one for XML, one for SQL, etc, and you'll want to set up read/write functions with the same signature. Leave it up to that class to determine how to communicate with it's actual database, but what I'm saying is have XML.setInfo(key: String, value: String) and SQL.setInfo(key: String, value: String)

You see where I'm going with that? What that allows you to do is integrate or remove any database at any time, assuming you keep the database's signature the same, without affecting your client application.

It does take a little more design the first time, but what you end up with is something you can drop in to just about any database project from this point forward.
SUMMARY:
Code: 
Client/GUI <-->  Database Handler <-- Databases (SQL, Access, XML, etc)

Now, on to the SQL. SQL isn't too hard to set up. Ideally you want to run it from your server, or set up a dedicated machine, like an old paperweight desktop. Wipe it out and put the bare minimum on it. You'll gain a lot of stability, scalability, speed, etc from doing that. edit: Again, that's ideally. You could run it from anyone's machine; I actually have mine on our test bench right now...(gasp!)... prolly shouldn't have admitted that

How many people do you expect to be using it?

FYI I'm fairly certain GnuCash lets you have multiple people use it at the same time... but again, I'd really spend a day or two checking it and/or other open source solutions out, because they've done all the work for you.
 
Last edited:
After your explaination, I am confused now.
I think what you are telling me is to write 2 software.
1 for the client machine. and the other on the sql server.
The main purpose of the sql server software will be to handle the function calls from the client software.

Ideally, I understand the structure of this application.
But I have never written any software similar to this.
Other than servlet.

Would you please point me to the right direction?
I am not sure what is this topic, therefore, I have no idea how to search for help on this.
Perhaps some examples will help
:confused:
 
What alreadyused is saying is that it makes more sense to break your application into segments. The base segment is your database. This, obviously, requires that you define all of your database functionality in one area. This is fine for SQL Server or MySQL, but you will be pretty limited with Access for this as it lacks the functionality available to the higher end databases.

The second level of the design will be your data access and, if you design it this way, business objects. The beauty of designing in this manner is that all your applications will be able to access the associated data sources through this one service or library. This allows you to create either wholey new apps later, or bolt-ons to the current app easily and quickly, without having to code the entire data section into each app.

One further level of design you may want to consider is a separation between your data access layer and business objects. Once again, this allows another separation level, allowing the data access layer to be used for absolutely any type of data access, and the business objects to be used for the current app for any type of interface module.

Finally, you'll have the interface design to consider. If you follow the n-tier design methodology you'll realise that you can create multiple types of document interface. The ability to split your interface design is very useful, allowing you to distribute reporting sections to one group of users, data entry segments to others, and user management to administrators.

There are a number of ways to do this with .NET. Firstly, you could create individual projects to handle data access and business objects. Test them and ensure they work properly. Then, you can create a solution and import these projects into your solution. Alternatively, you can create the entire solution in one go. It doesn't wholey matter which way you do this, but what I will say is: if you are going to pursue an n-tier method try and write your code in a very modular style - this allows you to utilise these code blocks in other completely different applications.

I hope this goes some way to explaining the usefulness of developing in this manner. It may take a little time to set up the basics, but once done it's all reusable.

Paul.
 

Attachments

I understand the n-tier archtecture design.
I was just not sure how to write software that communicate with each other within the LAN.
But thanks for all the help.
Now I am sure the method I am pursuing is ideal.
 
To be honest, all you have to do is centrally locate your data access layer and business objects layer on a separate server to your database. Your data access layer should know how to connect to the database anyway, and a reference to the DLL that drives your data access layer should be included in the business objects.

After this, if this is a web based app you are designing, you should only need access to the business objects. You can do this by including references to them in the various projects of your interface apps.

Good luck noodle. ;)
 
Back
Top