I have a case where I want to make tool for people in my company to use. It's a simple tool to import log-type data into a database, that tool should sort data and do some operations on it (like calculate difference between time based on previous record etc). But I'm restricted by corporation security programs so I have to stick to office and tools that don't require installing anything new.
I made access which do the job, but due to bad performance on even small portion of data I have to look for something else. Also Excel is not an answer due to limitation in number of lines.
Is there a way to make some tool that will use Access as database, but will do operations on data outside of it, and the result will be returned to access as completed table? For what should I look to make such tool?
Vb.net is a Microsoft language that is easy to learn, you can create an application graphically, you can connect it to access DB. it will really help you in your situation. I'm personally using it to create access data managing apps.
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?
What is the best way to centralize and secure the connections strings used by applications? In my environment we have many internal applications. Each application requires one or more connection strings in order to access the database. We have a goal of centralizing all these connection strings (particularly SQL logins and passwords) so we could change passwords in one place instead of in 35 different .config files, registry entries etc.
Currently we are using a home grown component which pulls the connection string information from an access database, this covers the centralization requirement but isn't particularly secure. In addition we have applications written in languages from classic asp, vb6, delphi, c++, .net so the solution would need to be usable by all those applications.
Does anyone have an idea of how to do this better, or do we need to rework our whole approach to the way our applications access the database.
The company I work for has used a similar situation through a SQL Server database instead. We ended up creating a COM-compliant .net dll to simplify and secure the API into the database and to ensure that the same logic is used between classic asp, .Net, and DTS packages. It has worked out great for us for year and while there are some refactoring items a lot of us would like to do with it, it's been great to address issues like server migrations or renamings.
I think you are on the right path; however, I would recommend the following changes:
Try to move to a true database server. Access is great for MS Office but not for something of this scale.
Build an administrative console that allows for auditing of who is adding and editing information (secure who has access to what settings too).
Build a COM-compliant DLL so that it can be consumed by other systems in a secure and consistent manner.
EDIT:
Something that I have noticed after working years in a system like this is that it ties your hands slightly on some solutions. Many tools out there (i.e. nHibernate, Elmah, etc. in the .Net world) really are limited when the connection string is no longer in the config files. Many can be easily modified to use your API; however, it is something that takes more time to investigate if you want to use it. Just a FYI on that.
You can use Windows server to create users that are allowed to access your SQL Server database. Then you can use integrated windows login in connection strings.
BTW Storing passwords in public MDB renders them irelevant. Same as they don't exist.
Is it not possible to move to Window Integrated Security in the connection strings, then you do not have to worry about the security aspect as much (unless you need to secure the actual location of the connection I guess).
I know that Open Office Database uses a java database backend. Does anyone have any insight on how this compares to the Jet Database Engine?
Also is the query designer/reporting nearly as robust as MS Access?
It's odd for me to say this, because I'm not a fan of Access at all. However, I think Access is actually the nicer product here, for a number of reasons:
It's been around a lot longer (maturity)
The core db engine is included with windows.
There's an easily distributable runtime if your users don't already have Access and you need to distribute an application.
Over the years it's had enough people try to use it for things it's not designed to do (web sites, workgroups) that they've put enough work into performance and concurrency so the two more recent incarnations (2003, 2007) are actually very robust if you're doing something it is designed to do (desktop crud app, talking to linked sql server tables, very small workgroup). (I guess this is really the same as the first point)
On the other hand, there's nothing wrong with the OpenOffice DB, and it's free.