This question covers a number of areas, so may ultimately have to broken up into constituent parts. However, I don't want to do this, at least until I have some general idea of what direction I should be taking!
I want to create an online booking system under the .Net Framework. The GUI would have two separate vital areas. 1. would be the typical form GUI for setting up a user account. 2. would be a Calendar (much in the same vein as Google Calendar - if not actually Google Calendar) which would show users available times that users can book, and hopefully allow them to actually book by simply clicking on an available time as displayed on the calendar.
The available times that would be displayed on the calendar would depend on two things: the type of user the user is (would be specified in the signup form) and also (obviously) whether or not other users have already taken available slots.
One big question I have is whether it is possible to use Microsoft Access (any version) for this task. My preference is due to familiarity, and the fact that most other technologies being used in this development are Microsoft based. I know it is possible to migrate Access DBs with SQL Server - but would this include the vital front end (i.e. the form)?
Finally, The strategy for approaching the calendar aspect of the front-end is doing my head in a little! While it is certainly possible to integrate SQL Server and Google (docs/calendar) I feel that attempting to shoehorn Google Calendar into such a complex relational database would be ultimately infeasible - but I am struggling to think of an alternative without having to do my own development (which, in this case, I am seriously attempting to avoid!)
Any guidance on the above would be greatly appreciated!
My $.02: as #Luxspes said, Sql Server has no "forms" or "reports", but the SQL Server engine is better suited to web-based applications than Access's "Jet" engine. You could, however, develop your application in Access and then "upsize" your database, which tells Access "hey, those forms and reports are great, but now I want you to put the back-end database into SQL Server Express (free) and keep the front-end in Access." You can then publish your forms and reports to the web using Access's own tools, getting them "for free" while getting the better database engine on the back.
Be aware that doing this is not generally acceptable in the commercial world. An Access application looks like an Access application and most of the world will recognize it, and most don't like it: it will seem like you're cutting corners unless you can make the forms look really, really good. For in-house use it's fine because it has a fast turn-around time so the ROI is great. If you're making a commercial site, I'd take a look at the Microsoft MVC 3 framework: it will take a while to get your noodle around it, but once you're up to speed you can develop sites pretty quickly and robustly. If "robustly" is a word.
Is it possible to use Microsoft Access (any version) for this task, the task being using Access as the database for a online booking system under the .Net Framework: Yes. (But I would prefer to use MSSQL Express Edition)
I know it is possible to migrate Access DBs with SQL Server - but would this include the vital front end (i.e. the form)?: No, SQL Server has not concept of "forms". If you already have them in Access you would have to re-create them in, for example, ASP.NET. If you are looking for the easiest fastest way to do it, I would recommend you LightSwitch ( http://www.microsoft.com/visualstudio/en-us/lightswitch )
Finally, The strategy for approaching the calendar aspect of the front-end is doing my head in a little!: If you do no want to code it, you can find it in Google, just write ".NET Schedule control"
Related
Need a easy to set-up and flexible web front-end for a data warehouse built in SQL Server 2008. I'd like to be able to expose both SSRS reports and SSAS cubes for browsing.
Seems like Microsoft wants us all to use Sharepoint for this, but I want something I can expose to internal users as well as customers, so I don't think Sharepoint will work (right?).
The other big approach people take seems to be coding up a custom ASP.NET app, which I have no desire to do.
Basically just want something like Cognos or Business Objects, but as a front end to SSRS and SSAS, not some proprietary data structure.
Why is this so hard to find - seems like it would be a common need. Why doesn't Microsoft make this?
Only one I've found so far is Report Portal (www.reportportal.com), which seems pretty good, but not stellar. As far as the big guys go, it looks like MicroStrategy (microstrategy.com) can work with native SSAS cubes, but for general reporting has it's own structures. Graphs and interface look good though, so would appreciate hearing from anyone with experience integrating Microstrategy and SQL Server as well.
Thanks!
The Enterprise version of SharePoint does what you want and more. It is also able to handle external users, but that requires some serious thought to architecture etc. However Enterprise SharePoint is not cheap, nor is a SharePoint farm installation a minor exercise.
Having used SharePoint to do this, it is very powerful, but does not work well over SSL, so terminate your SSL at the F5 or other hardware.
For information on planning a SharePoint implementation, have a look at
Planning an architecture for SharePoint server 2010
also Extranet topologies for SharePoint 2010 Products
Running through the rather large amount of documentation here should give you a glimpse of what is involved in getting a SharePoint extranet working.
Would be really interested in a good "non-sharepoint, non-BI" answer. I see this question asked all over the place with people specifically saying "I don't want to use sharepoint, what are the alternatives." and invariably the next 200 answers are "Use sharepoint"
If you're a SQL/Asp shop that just does standard web, sharepoint and BI are both megatons of bloat just to get internet/intranet report delivery.
So the answer is "No there's not a "Front end in a box" other than the ones you've mentioned. Go kickstarter one as this is one of the most frequent searched on pain-points I've ever seen with the least amount of viable answers/solutions.
Our company is upgrading all work computers soon and no longer supporting MS Access. Unfortunately, a lot of important database is stored in a plethora of Access databases with many differing styles of interfaces. Storing it all on a database server is out of the question. What is a good portable (non-server) database system that I can use?
The one I'm leaning toward is SQLite, but I'd also like to be able to write interfaces to query the data. If I use SQLite, what is a good way to write a query interface that will work on a lot of Windows machines natively?
EDIT: Data migration will not be a problem. I'm more worried about interface migration. What is a good way to write a query interface for one of these portable database systems?
EDIT2: It seems that there's some confusion as to what I mean by "query interface". I don't need a complete query system. I'm simply looking to create a simple frontend through which I can search the Database by table and by fields.
Judging by the title of your question, you are concerned about what database (i.e. data container) should be used in place of Microsoft Access. However, viewing your question and the ensuing answers and comments, your greater concern is actually what to use to design the Application/user interface, what you are referring to as the "query interface".
Here's a couple things you need to realize:
1) SELECT queries allow you to extract data from a database. However, the data has to get into the database somehow. At no point have you specified whether or not your so-called "query interface" is also used for data entry. If it is in fact used for data entry, as I suspect it is, then you should concern yourself with how your going to design your "application", not your "query interface". Data entry often requires a certain amount of guidance and logic that is defined outside of the database. This logic includes (but is not limited to) things like validation rules, input masks, parent child relationships that are enforced by the GUI design. This is essentially an application, not merely a "query interface". Applications are usually designed to make data entry easier than having the user enter data directly into the tables. But even here you must realize that ultimately a user can't even enter data directly into a table without some type of application GUI, whether that GUI is something you've designed or not.
2) Microsoft Access is a Rapid Application Development (RAD) tool that allows you to quickly and easily design and save queries, forms, and reports. It appears to me that you're real question is, What RAD tool other than Microsoft Access can I use to develop queries and forms for viewing and entering data in small desktop databases? And what database would you recommend we use together with the RAD tool you're recommending?
Assuming I've properly defined your actual question, allow me to give my own viewpoint on this question. First, as has already been pointed out in another answer, as long as the clients are running MS Windows, you don't really need to move away from using Access/Jet/ACC as your database (data container, the part that holds the tables). As long as MDAC is installed an Access database should be "machine readable".
It seems to me the more important question here is what RAD tool should you use in place of Microsoft Access? After you answer this question perhaps it will help you answer the first question, of what database should be used. In answer to this question, let's be honest. While Microsoft Access has it's shortcomings, you probably won't find any other RAD tool that allows you to so easily create Forms for data entry. FileMaker Pro is one of the only competing products that I know of.
Yes, you could use Visual Studio .Net to create .exe runtimes. These runtimes can include forms for viewing and entering data as well as reports. I think you'll find that the learning curve is pretty major, especially if you are not yet familiar with ADO.Net which is very different from DAO or ADO Classic. If you want to give your users ways to create their own queries/filters or reports you'll have to design this functionality into your GUI since Visual Studio doesn't give you the easy wizards and design tools you'll find in Microsoft Access. While Visual Studio is far more powerful than MS Access, you need to realize that the development time for even the simplest of applications is probably going to be much higher, especially when you are first learning.
Are there any other RAD tools you could possibly use? I know little if anything about the different design tools listed here but this might be a good place for you to start: http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools#Desktop_Rapid_Application_Development_Tools
SQLite is a great option and will extend your reach to many platforms beyond Windows (iOS, OSX, Android, etc.). I recommend this. If you want to keep using Microsoft products, SQL Server Express or Compact Edition is another possibility.
Another solution, depending on what you are doing with these databases, would be Microsoft SQL Server Compact Edition which does not require an installer.
No matter what database you choose, you are going to be faced with migrating your queries to a different dialect of the SQL language (the actual syntax of your queries). They all have their quirks and features (and missing features). That is just the nature of the beast. It should be noted that you can still access a MS Access database in code without requiring the installation of MS Access.
It appears that the nature of the question has changed dramatically since it was originally posted. The question has apparently morphed into one about finding an user interface development environment that has similar features to Access. This is obviously an entirely different question than finding a replacement for Access (or specifically Jet for those anal retentives in the audience) as a database engine.
There are many alternatives and it depends greatly on whether you wish to continue with a Windows application or whether you wish to move to a browser based interface. Given various comments, it sounds like you may still want a Windows based solution. A couple of solutions you might investigate:
.NET Windows Forms - The .NET environment is incredibly powerful and provides for very rapid development. IMO, as rapid as Access if you know what you are doing and far more powerful. However, with those additional capabilities comes additional complexity. No question that jumping into Windows Forms from pure Access development will be daunting but rewarding.
Another solution, which I admit to not having tested myself, but looks promising is Kexi + SQLite which is geared as an open source replacement for Access.
If you considered changing gears and switching to a browser based approach, there are again many choices. PHP, ASP.NET (MVC and not), Ruby and so on. As with Windows Forms, switching to browser based development from Access development will be a daunting change but also rewarding.
Of course, if the PHB are eliminating Access as a cost cutting move, you could split the existing Access databases to Front-end/backend applications, migrate the backends to SQL Server Express edition (free) and have the users use the MS Access run-time (also free) You, the developer, are the only one who actually needs a paid-for full version of Access.
This response comes long after the question was posted--but Google still turns it up near the top of results for 'replace ms access'
You should include MySQL and PostgreSQL on your list of the potential replacements. MySQL supports AUTO_INCREMENT columns, so it might be a better replacement for the Microsoft databases. Also, Microsoft SQL Server Express might be not a bad option. I migrated from using MS Access databases to using MS SQL Server Express in my apps when I was using Microsoft technologies about 10-12 years ago.
What are the strategies you employ to let multiple people work on an access database?
Is it possible to host it online and have its features still functional without having to develop a custom frontend?
MS Access as a software has a few nice features that don't require any programming to configure:
Drop down lists - choose one
Multi Checkbox lists - choose multiple
Is it possible to get all of these features available even when hosted online? I'm basically thinking of an alternate way to quickly get people to work with data using GUI features like the above without going the webapp<>MySQL way.
You have some good comments here. Keep in mind that things have changed quite a bit for access 2010.
Access 2010 allows you to build web applications. The development process is very much the same as it’s been for years, but you can’t use VBA in forms for these web applications (you use a new macro language). This new feature set allows you to publish applications you build to a website. Here is an video of an application of mine running in access 2010, and at the halfway point in the video I switch to running the access application 100% in a web browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
The above is for access 2010…due out this year. The above will require you to be running SharePoint services, or use an hosting service that supports "access web" services.
For previous versions of access, for all intents and purposes, it’s not a web based system at all. Now when you say multiple users, you have to clarify what kind of users and where they plan to be. If your users are on a local office network, then MS access can be used as a multi user system right out of a box with no additional coding and programming required. It is recommended however that you split your application into a front end part that’s deployed on each user’s computer. This Concept as outlined in the following article of mine.
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
Now, perhaps the users are going to be on notebooks and in different locations all over the country? In this type of case you are attempting to connect over a wide area network, or have users connect to the application over the Internet. This is a different problem. In this type of scenario, a good solution is to use something like SQL server for the backend, and you continue to deploy the Access front ends to each user’s computer. This application tends to be about the most cost affordable also. And using sql server + ms-access means you get to continue developing in Access for the most part like you always done. Another way to accomplish wide area use without resorting to sql server is to use something called terminal services. I outline these possibilities in the following article:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
As mentioned, a few others here posted links to some of the new SharePoint features that you can consider using, but they not out untill later this year.
Multi-user Access apps are pretty easy to do for small workgroup user populations in the 15-25 ranger or smaller. Above that, a developer should consider upsizing to a server back end, with the trade-off being greater administrative overhead for the server vs. having to program the app more carefully if you retain the Jet/ACE back end.
As to online access, you this isn't possible over HTTP, but if you have a Windows Terminal Server available, you can host your app there and give users access to that. This is actually an extremely easy and efficient and inexpensive way to support remote users of an app, though the larger the user population, the more problematic it becomes. But by the time an Access app has a user population that would strain a Windows Terminal Server setup, you're no longer going to be using a Jet/ACE back end.
And with a server back end, you could give access to a SQL Server on a VPN over the Internet, and if you write your Access app really efficiently, even over a standard broadband connection, your users could still work productively.
Then there's the future of Access: in Access 2010, a great deal of work has been done to integrate with a host of new features in Sharepoint 2010. If you create your A2010 app using the new type of Access web forms and reports, your app can be uploaded to a Sharepoint server running the new Access Services, and it can then be used running in a web browser (not limited to IE and not dependent on any plugins or web controls, as was the case in the past with the completely worthless Access Data Access Pages). The data store can either be a SQL Server, or you could keep it Jet/ACE for users not accessing it via the web browser, and have the data stored in Sharepoint for the online users. Also, you can have an app integrated with Sharepoint running locally in Access that uses Sharepoint when connected to the Internet, and still be able to work offline when disconnected. When connected again, you synch your local changes with the Sharepoint server, resolve any differences and continue working.
The features are really quite remarkable, and according to what I've heard and seen, if the Access app is built entirely of web forms and reports, it will look and function identically when run in Access and when run in the web browser via Sharepoint. And if you need to have client-side features that you don't expose to the users running the app in the browser, you can still use traditional Access objects!
The Access development team's blog has a number of posts on what's coming in A2010, and there's a good video posted there demonstrating how A2010 integrates with Sharepoint 2010's new Access Services.
This constitutes a quantum leap in Access's web capabilities, which were previously almost non-existent, and I'm quite excited about this. I was formerly quite wary of the changes being made to Access that seemed entirely to make it a servant of Sharepoint, but now I can see that the benefit to Access users and Access developers will be huge.
One way i've heard of, is to import the access database into a SQL Server database.
(Almost any version will do.).
Then link to the SQL Server database with Access and let users use it as they did before.
Look at this link: http://office.microsoft.com/en-us/access/HA010345991033.aspx
If you want an online solution i'd recommend going with a normal web application architecture. (Talking to a proper database.).
I have never needed to support it myself, but from what I heard so far, performance dramatically breaks down as soon as you need to support multiple users writing simultaneously. I think this is because Access uses simple file locking to implement isolation, and this just is not the right technique for a concurrent database system.
Hosted on-line? Do you mean on the network? Technically it will work on a network but there is a reason MS-Access in not in Visual Studio - it is not considered a development platform - it is a desktop application. When MS-Access first hit the scene many people built applications using it. The multiuser functionality just is not there. Upto four or five users is ok. But I would not go for more.
I'm hoping you can help.
I'm looking for a zero config multi-user datbase that my winforms application can easily upload to a webserver folder (together with 1 or 2 classic asp pages) and am looking for some suggestions/recommendations.
The idea is that the database will be used to collect feedback entered by people filling in the asp pages. The pages will write to the database using javascript.
The database will subsequently be downloaded again for processing once the responses are in.
In Summary:
It will mostly run in MS Windows environments.
I have a modest budget for this and do not mind paying for such a database.
No runtime licensing costs.
Should be xcopy - Once uploaded to a website folder it should be operational.
It should not have a dotnet CLR dependency.
It should support a resonable level of concurrent access. Average respondent count would be around 20-30 but one never knows.
Should be a reasonable size so that uploads/downloads to and from the site will be reasonably fast.
Would appreciate your suggestions/comments
Many thanks
Abz
To clarify - this is a desktop commercial application for feedback management in a vertical market. It uses SQL Server as the backing store.
The application currently provides feedback management from email and paper feedback. I now want to add web feedback capability. Getting users to to make their SQL servers accessible to a website is not at option at this time as I am want to make getting up and running as painless as possible.
I intend to release a web based implementation of the software in the near future but for now am looking at the above as a pragmatic way to provide web based feedback collection.
SQLite comes to mind. It meets all of your stated requirements, is open source, and has a liberal license (public domain).
http://sqlite.org/
I would use 'normal' database (say MySql, Postgresql, Firebird, etc.) on server. Instead of copying files to server your winforms application would create custom tables (or even custom databases). After collecting data you could just get it back to your application using plain old SQL.
why reinvent the wheel ? If you want to collect feedback and stuffs from users of your app and if they are connected to internet, it might be a better idea - and in the long term cheaper - to use a service like wufoo. We recently switched from homegrown setup to wufoo and are very pleased. Check it out.
Otherwise you might want to take a look at sqlite orfirebird. Both of them are very robust, and have ADO.NET providers. Firebird scales from a single user to full blown client server system and has no .NET dependency.
If you really don't want a DB/SQL Solution, you could try simple text files and ftp/xcopy files down and parse them into the back-office server as needed. ASP/VBScript or ASP.NET can create the files to store the basic feedback comments. Need to consider security of course!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Background
I work for a large organization which has thousands of MS Access applications floating around. I didn't write any of these - in fact, most of the original authors have long since left the company - but from time to time another Access app lands on my desk for support. I would soooo love to replace access with a different solution.
Requirement
I know that there are several good alternatives for the database part of MS Access (the Jet database), such as SQLite, MySQL, VistaDB, etc.
What I would like to know is: Is there anything that will replace the front end part of MS Access?
I.e. Something which can be used to build forms, write simple scripts and queries, etc?
Why?
#BracC asked "why replace access?" - A fair question indeed.
I want to get rid of access because:
it hides logic, leading to hard-to-support applications. Logic can be in lots of different places, none of which provide or encourage any structure:
macros
modules
queries
forms
its very nature encourages users to create "little" applications which become "not so little applications". Then the user leaves and I have to support a bunch of spaghetti. I know that access isn't the only culprit, but it's the leader in my organisation, and I would love to get rid of it completely.
For extra credit
what I would really love to find is something which can read in an MDB file and output something like C# which replicates the functionality. (Or any language - not fussy).
I hope this is all clear. If not, please post a comment and I'll re-write/add detail.
Update
#GuinnessFan makes some points I find interesting. I have added my comments to discuss those points.
What we have done since I asked the question:
Got users to give us a definitive list of access applications they use and need. (The understanding is that any MDB files not on the list can be deleted - hooray!).
Analysed the MDBs on the list, coming to the following conclusions:
Most of the "applications" consist of a single hard-coded query or a single linked table.
Many are a small number of queries with, perhaps, a date parameter or similar.
very few (if any) have any truly complex logic.
We are now working through the list, converting most of the apps to SSRS (SQL Server Reporting Services) packages.
Anything which can't be replicated using SSRS will become a hand-crafted web application. However, there aren't many of these.
May I say many thanks, to everybody who has given me helpful answers.
I switched the back-end on one application from MSacces to MSSQL a few years ago. Kept the front-end, because it worked well, and I didn't find anything as easy to use/modify.
I've never seen a MSAccess -> C# translator. However, you might be able to find a MSAccess to VB6 translator (their syntaxes are roughly similar), and from there there are VB6->VB.Net translators (and even VB.Net ->C# translators)
You could check out Oracle's Application Express. It's free and it's geared toward Access developers.
It has a migration assistant as well that you run your Access database through, it proccesses the data and the forms, migrates everything to an Oracle Database (this works with the free database, Oracle XE, and comes install by default) and builds web forms for your Access database.
So in the end you'll have your Access databases on the web, your data in Oracle and somewhat nice web front end for extending them.
As far as Oracle goes, the tool isn't half bad. You can sign up for a free instance to play around with here.
Here's the document that explains how you migrate Access Databases.
So, other than personnal distaste, why replace the Access front-end? May be easy to do for some (simple) databases, but most Access apps in the real world have a lot of complexity.
Lots of reasons for upgrading the back-end, of course (scalability, performance, db corruption, user-locking). Access even has a built-in "upgrade wizard" tool that allows you to split the forms and logic from the data, and upgrade the data to MS SQL server. If you want, use this wizard to upgrade the back-end to SQL Express, then manually migrate to another db platform.
Hope this is not too far off-topic, but sometimes all you need to do with Access is:
Upgrade the back-end (as we've already discussed)
Always make sure the front-ends are locked down (read-only)
If necessary, create different front-ends for different user roles (as a form of security).
If possible, have the front-ends copied locally on each workstation, for performance reasons. You may need to have a network script to check for new versions of the front-end.
I don't have any direct experience with it, but I did find an Access to ASP.Net converter tool called "Access Whiz" at http://www.microtools.us/
We used an internal app based on MS Access as a frontend to a MySQL database. We ran into lots of problems, and eventually rewrote the whole app in CodeGear Delphi 2007 for Win32. This has been a great success, although the migration did cost quite a lot of effort (training/hiring a couple of Delphi programmers, buying some third-party tools). I can wholeheartedly recommend Delphi, though. And AFAIK, integration with a MS Access back-end is certainly possible --- I once wrote a Delphi app that does just that, and it only cost me a couple of days to get a feature-complete version!
I realize this is a full programming solution, so you'd definitely loose some of the ease-of-use of MS Access for building front-ends. Then again, you can put together a database application in Delphi in 10 minutes without writing too much code --- no kidding! And since the 2009 release, the language is slowly becoming more mainstream again...
#BradC
I don't recomment MicroTools. I worked for a company a while back where we had the same problem. Unless MicroTools has made significant improvements to their product, it spits out garbage last I checked.
What we found was that pretty much any upgrade path will require significant amounts of coding changes. All these tools are good for is to maintain a similar GUI from the original application. Their code had no object structure, just a bunch of utility functions that were dumped on each page to simulate the way Access provides record navigation. If you have a large number of forms, pulling out their solution and implementing your own takes some work and a ton of find-and-replace operations.
We were so disappointed with MicroTools performance that we started writing our own converter. We were pumping out better ASP.NET forms than they were after a week of coding.
You won't find an server-class engine that also has the desktop interface design tools attached. The big server engines all expect you to use something like C++, C#, Java, or PHP to build your interface.
I, too, would love to see an upgrade tool for access that would spit out some basic C# forms and talks to an equivalent SQL Server database. It seems that would be a big money-maker for Microsoft because they could use it as a way to up-sell customers to a full SQL Server.
IIRC, there might be a way to tell an Access front end to talk to a SQL Server, or change the tables used by an Access front end to really be linked tables into a SQL Server, or something like that, but I've never had to use the feature myself.
I have a different perspective for you to consider. Your main issue is that it hides logic and there is data and applications scattered through the organization.
Unfortunately I don't know of a RAD (rapid application development) tool that is as easy as Access to create functional forms.
However I would recommend that you focus more on the possibility of centeralizing your data and logic and still allow Access as a front end. I support a database product called Advantage Database Server which supports RI (refferential integrity) rules, stored procedures, triggers, etc. that can all be managed on a centeral server thus bringing all of the logic to you. These Access front-ends could then link to the data backend using ODBC or OLEDB. If you switched to a solution like this then later down the road you would have flexibility to write other applications such as .NET, PHP, JDBC, etc. that tie into the same data while phasing Access front-ends out.
A good start would be to stop new Access development unless they're using this sort of data backend.
Out of the 1000's of Access files how many have you been asked to support? I'm guessing less than 100. Why rebuild an application that A) no one uses B) works fine just the way it is?
You need to begin a policy that it is an acceptable practice for a large organization to develop custom applications in a robust, scalable, reliable, yadda yadda yadda environment. Identify the Access applications you feel are critical or are being outgrown and just work on those.
Be prepared to handle the expectation of getting their quick and dirty little applications on a quick turnaround. You'll have to show them the benefits of your new apps.
I think you just need to be a resident expert and teach these users how to improve their application or get your input from the beginning to start them off right. The requirements to convert all of these files would otherwise be overwhelming.
Microtools offers Access Whiz, a set of Access conversion tools. It consists of Access to ASP .NET (VB/C#) converters, Access to VB6 converter, Access to WinForms (VB .NET/C#) converters and Access to Crystal Reports converter. More information and trial demos can be found at http://www.microtools.us.
You can also take a look at Firebird
Here is the way to migrate (you need Delphi)
I also find this MDB2FDB
Is there anything that will replace the front end part of MS Access?
Maybe Kexi?