1

I have an existing Access Database with forms and reports. This was done back in 2000. At the time of development it was purely to put out fires and get something done for people to start capturing data in a database format, run reports and filter results.

I have no idea who created it as the person has since left and left no traces of what he did. I can access the files, log the data and get to the code so theres no problem with the integrity.

My question however is. Since then are there better alternatives to capture data in a database that is easily accessible with an easy interface and reporting feature like Access. I know that there are alternatives like MSSQL, MySQL etc but dont want to go down that path as an interface still has to be designed for that type of DB anyway.

PeeHaa
  • 71,436
  • 58
  • 190
  • 262
GrimR7529
  • 609
  • 1
  • 5
  • 21
  • 2
    MS Access isn't always the right tool for the job, but if this is stuff that's accessed by a single user at a time and does the job as is, may as well not mess with it. – Roman May 31 '11 at 00:55
  • It would be nice to be able to have multiple people access it at any one time. I know isnt strong in this and is not really intented for use by multiple people, but would be nice if it could... Forgot to mention up the tob, but we would like to add and change what the DB does, so, do we keep it and tack on or do we redo in something more modern with better capabilities – GrimR7529 May 31 '11 at 00:58

5 Answers5

7

There are various database management tools along the level of Access listed at http://alternatives.rzero.com/db.html and Alternatives to Access. The problem is that migrating data is often fairly easy compared to forms and code.

If you have an existing application that is working OK, but not well documented etc, then I would stick with that. Understand the application, document it, and work out future requirements before trying to move it to another framework. You have some flexibility with Access if it is working OK for the current users.

  • It is possible to use Access as a front end to SQL Server.
  • Access is trivial to use from almost all Windows development tools. So if you need to write a new front end you can gradually do this.
  • Access has varying level of integration with SharePoint. For simple applications (I don't know if yours is) a lot of people are looking at SharePoint lists and views. This is not always the best decision, but it is worth a look.
Community
  • 1
  • 1
Brian Lyttle
  • 14,558
  • 15
  • 68
  • 104
  • 3
    #Brian Lyttle is right: It would be a mistake to leave Access for another interface without any other argument than "finding a better alternative to it". Depending on its use, you might not be able to find any. – Philippe Grondier May 31 '11 at 04:50
3

VS Lightswitch might be worth looking at.

Jason
  • 86,222
  • 15
  • 131
  • 146
  • I had a look at this. Seems pretty good for what it is. I think though that if I was to go for something like this I would wait until its better supported. I can fiddle my way through Access easily and there is a lot of help. With Lightswitch I mind find that it was better to just have stuck with Access. Thanks for the idea, will be kepping this one in my back pocket for later. – GrimR7529 Jun 02 '11 at 04:02
1

If you have fairly straight forward CRUD needs for your data you could try moving to MS SQL Server and using ASP.NET Dynamic Data to generate an interface. Sql Server Reporting Services could then be used to handle reporting needs. Microsoft provides some tools to help you migrate data from MS Access to SQL Server. This would also give you a path to add custom functionality as the needs arise.

To expand a little bit on adding functionality later. ASP.NET technologies can live side by side within the same application. So in your case you might start out with Dynamic Data as the interface, then as needs arise, add custom ASP.NET MVC forms for [some business reason] and maybe expose some of the data over WCF web-services for consumption by other applications. This way you can incrementally grow into your needs without a heavy upfront investment.

Roman
  • 19,581
  • 6
  • 68
  • 84
0

"Since then ...2000" ? I think the later versions of Access are much better (2003-2010). This way you can do an upgrade instead of a conversion.

If you're trying to avoid licenses for multiple users, there are ways to build the app (Still need one license) and distribute to others. They lose the ability to create things on their own.

I would split the application into two files: A) Data Only (put on shared drive) B) Application (create user copies to place on their HD and link to data file). From here, you can deal with any performance issues if they come up.

Unless there are other flaws with your application, you could do this in a day or two.

JeffO
  • 7,957
  • 3
  • 44
  • 53
-2

use sqlite

And search for interfaces, there are many

RoboTamer
  • 3,474
  • 2
  • 39
  • 43
  • We would then have to program an interface and all the reporting features etc. Not as simple as Access – GrimR7529 May 31 '11 at 00:59
  • 1
    Saying "search for interfaces" doesn't really answer the question. – Roman May 31 '11 at 01:06
  • Terrible, near-idiotic answer. The question clearly speaks mostly about the user interface aspect of things, and this answer basically dismisses that as some kind of minor triviality. – David-W-Fenton Jun 03 '11 at 03:36