I've been interested in 4D SAS' database product for a long time, though have barely touched it in eons.
In considering what tools to use for application development, especially one that will require a database component, what should be looked for when considering open-source tools like MySQL and PostgreSQL vs proprietary solutions like 4D or Pervasive SQL?
What good (and bad!) experiences has the SO community had with various DB tools like 4D, Pervasive, FilemakerPro, etc?
Any bad experiences?
Difficult to make a relevant list of Pros and Cons without a context.
My advice would be the following: when making the decision of using a proprietary database, make sure that this decision is based on strong facts and not merely a technical interest for an exotic tool. Put into the balance the benefits for using the proprietary database and the advantages of a non-proprietary solution.
The answer is different from system to system.
A prerequisite is that your system is well identified, with a clear scope, a quite predictable evolution, so that the results of your analysis will be robust. Then, if your proprietary solution brings a real benefit for your system, that you are comfortable with the support and that you can afford the overall cost, you should be a good candidate for the proprietary solution.
4D is a MacOS/Windows only cross-platform, proprietary database system with both stand-alone and Client-Server varieties. You would do well to compare it to Alphafive.com software which is Windows only. I've worked with it for 17 years and it has served me and my department very well. Off the top of my head ...
Pros:
Interface & code are closely tied to the data engine which makes development of rich, cross-platform user interfaces very fast and easy.
Proprietary relational data engine runs natively on both platforms, along with native client interfaces (but requires licenses for multi-users). Auto-relations are helpful (but sometimes get in the way).
Can access external systems via SOAP and ODBC and SQL drivers (limited).
Can access 4D from external systems via SOAP or http requests & web pages.
Native procedural programming language based on Pascal and is EASY to learn.
Excellent tool for small to mid-sized departments.
Latest version accepts subset of SQL commands AND original data access, so it's backward compatibility record has been very good.
Security is EASY in 4D.
You can build solutions to deploy through a variety of means, and are not limited by whether or not MS Access is installed.
Cons:
Interface & code are closely tied to the data engine which can lead to limited use of abstraction and "black-box" coding unless you make it a goal of your development.
Compiles to one monolithic structure file forcing restart for single fixes.
Language is still only procedural--making it harder for object-oriented programmers to accept. Every method requires separate "file" in 4D so you can't include more then one function or procedure in a single routine -- it will take some getting used to it.
While company appears to be in good shape, growing and developing, you simply never know as they keep their condition to themselves.
Company has never really marketed itself--trusting in its developer base to spread the word and grow the product through site deployments and product upgrades. Web site is clearly useful only to developers who already use the product -- it simply fails to attract new users.
Product upgrades have always seemed to focus on how the tool is better for the DEVELOPERS rather than for the CUSTOMERS of those developers.
SQL lacks views, compound indexes, and other common SQL features.
When a user requests a report of specific columns of data, I often have to write yet another program just to provide that specific data -- I can't always just query the data and generate a text file.
Does not handle new OS versions with nearly the ease of web browser based applications. Older version is broken on Mac OS 10.6, and newest version requires the latest Mac OS 10.6. No version is certified yet on Windows 7.
I've been nearly a year at learning ASP.NET and a few weeks at Ruby on Rails. While SQL data stores are EASY, user interface is HARD -- but worth it when your application still functions through OS upgrades. You can always use an older browser if the latest version breaks something.
I'd recommend you consider either of those, depending on how much funds you have available to implement the project--Rails being the cheaper of the two. Then, ANY system with a web browser can access the data, and you can fix interface pages on the fly as needed rather than taking the whole system down a few minutes for a single, simple update. Those skills might be more marketable in the future.
I will only say one thing.. Watch the "actual" cost of your decision.. Most proprietary database systems are Windows only.. or sometimes Mac/Windows only.
This means that along with paying quite a bit of money for the database system, you must also pay a good amount of money on a Server operating system to run it...
Also, compare the database system with current open source solutions. Is it really worth it? After moving from Microsoft Sql Server(which has a free edition, but anyway) to PostgreSQL I was blew away that people pay so much for SQL Server.. I mean, Postgres to me is a lot more clean, and most of it works exactly how you'd expect(unlike in certain SQL server syntaxes) and it has more features built into it(programming stored procs in Ruby anyone?)
So basically, compared the proprietary with the open source software and decide upon which one to take by total pricing(including OS) and feature set..
Pro of zeroing in on any DB: it's got good non-portable features that help you get things done
Con of zeroing in on any DB: sometimes a different DB is appropriate (for example running your tests with in-memory SQLite instances), but that option is now closed
Con of a proprietary commercial DB: if you need many instances, licensing costs can kill you
Consider the following questions:
How easy (or difficult) is it to make changes in maintenance? Applications are likely to spend far more time in maintenance than they do in development, so if changes are hard, long-term pain is guaranteed.
What is the quality of support? A system that is well-documented, proprietary or otherwise, is going to be easier to work with.
How large (or small) is the user community? Systems with larger user communities mean more people to ask for assistance if and when things go wrong.
How robust are the import/export capabilities of this proprietary database system?
I found the last point particularly useful at my first full-time job. Our client was using CA-Ingres, and no one at the company knew it well enough to write queries to validate the data. So I came up with the idea of exporting the data from Ingres and importing it into MS SQL Server (which I knew from a brief stint at Sybase Professional Services) so we could write our validation queries there. If it had been really hard to export data from Ingres, my idea wouldn't have been an option at all.
From 4D's webpage, I gather that we are looking at a complete development+deployment environment, not a standalone database as such. So the alternatives you could be looking at include stuff like django, ruby-on-rails, hibernate and others. The real question, of course, is if the proprietary system can save you enough money doing the product lifetime to justify the costs of the product. And that would depend on the type of human resources you have available.
4D is a good option for vertial applications. I have worked for a company which used 4D to build a medical records and billing application for general practitioners and specialists. The rapid design and deployment features of 4D enabled the application to quickly move with market desires and legislated changes to medical record storage.The environment itself was not cutting edge, but it was integrated, cross platform and very productive.
If you are entering a market with high vendor lock-in and a high barrier to entry, then I think proprietory integrated development environments are a good option.
At various points in my career, I've used and gotten very good at FileMaker Pro, FoxPro, 4D, and a few other commercial products. Now I mainly use PHP/MySQL, and haven't used the latest versions of any of the products.
I've always liked FileMaker because most people who can use a computer can pick up FileMaker and design their own systems. They don't have to know programming or database design. But, you can "program" FileMaker, put a web front end on it, or do other more sophisticated setups if you need to. Many times I was "handed" a system created in FileMaker by a non-technical person that needed to be made into a full fledged data management system. The good part was that all the "specs" and data flow were already designed into a system. The prototype was already created!
4D and FoxPro I always found required a certain amount of extra programming and/or database knowledge to really do anything with. 4D & FileMaker are really complete self-contained systems, not just database systems. Although they all have the ability to hook into other backend databases systems (i.e. MySQL, Oracle), that is not their strong point.
On the downside, doing more complex, dynamic systems can be difficult in 4D and Filemaker due to everything being tightly coupled. Because of their cost, you really would want to create multiple systems with them. Which means you need to really "buy into them" to get your money's worth.
The key concept is always adherence to standards: if you plan to use 4D's custom and / or special designed functions (but the discussion could be far more general, and cover any other free or commercial tool in the wild), well, just use it and take your advantage.
Not surprisingly, that's why huge DB systems like Oracle or IBM's DB2 in the past were wide accepted for specific business areas, as commercial transactions, for instance.
The other main reason to adopt a very closed solution is the legacy support. One of the products you cited (Pervasive SQL) acted as a no-effort port for BTrieve-based applications in late 90s, and it gained popularity thanks to the huge BTrieve community all over the planet.
Finally, last but not least, you should evaluate the TCO (Total Cost of Ownership) not only in terms of license price (single seat, network environment, site licenses and so on), but also for what concerns tech support, updates and availability for your platform. Many business units I know have been obliged to change their base OS for DB related problems.
Tip: add a bonus for custom solution that are proven or supported for usage in virtualized environments, if you aren't in seek for extreme performances. It will save more than a head ache for your DB manager.
In all other cases, rely on opensource/freesoftware DBs. MySql and Postgres for big projects, SQLite for single app persistence layer. Fairly standard and very good (community) support. Good value for no price.
I don't have any experiences with the proprietary database products you listed: 4D, Pervasive, FilemakerPro.
I'd be interested in knowing what those products offer that make them more attractive to you than the open source alternatives, you listed: MySQL and PostgreSQL.
I'd be interested in what makes those more attractive to you than the much more popular proprietary alternatives: Oracle, SQL Server, DB2, etc.
Without you providing more specifics, it's hard to advise you.
I personally feel safer using a widely used open source solution than a narrowly used closed source solution. The more widely used, the more battle-tested it's likely to be. The more open, the more control over my own destiny I have in case I do encounter some bug.
I have reported bugs to open source projects and gotten a quick fix. I have reported bugs to companies that make for-profit proprietary software and have gotten nothing.
Related
I'm working in a reporting service application where I use ETL/DWH/BI using SSIS packages for ETL and SQLserver for Data warehouse my client wants to know why should they would go for one solution with ETL/DWH/BI rather that specialized solution for each of these?
I will pleased for any suggestions.
Thanks
Business needs vary, no-one will be able to tell you what you should do for your client without analyzing that clients needs.
However, general reasons for using the SQL Server family of tools include:
All components are supported by the same vendor (Microsoft). This can help prevent the finger pointing when you have a problem integrating tools from different vendors.
In general, compatibility issues are reduced by using a single vendor and feature overlap is less common between tools within a suite.
Licensing/acquisition is streamlined. Buying from a single vendor will generally require less overhead than buying from multiple vendors.
Consolidated technical base. In my experience, there is a lot of overlap in the skills of an individual professional. Other than a non-development DBA and entry-level developers, the SQL Server professionals I have worked with generally have at least a functional understanding of the full suite of tools. I've yet to work with someone that can only produce in a single tool (SSIS, SSRS, etc). When you have tools from multiple vendors, you will have a harder time finding candidates that already have knowledge of all of your tools. This may not be an issue if your staffing needs do not force individuals to wear multiple hats or your volume of work in each category (ETL, Reporting, etc) requires dedicated resources.
Some downsides
Rarely are all of the tools "best of breed". The tools may be very good, but a focused competitor can generally out perform a suite in some areas.
Vendor lock-in is even more likely. If a tool falls behind the curve, it can be much harder to replace when the tool is part of a comprehensive suite.
We have about about six systems (they are all internal systems) that we need to send data between. Currently we do not have a consistent way of doing this. We use SSIS, SQL Server linked servers to directly update databases, ODBC connections to directly update databases, text files, etc..
Our goals are:
1) Have a consistent way of connecting applications.
2) Have a central way of monitoring and logging the connections between
applications.
3) For the applications that offer web services we
would like to start using them instead of connectiong directly with
the database.
Whatever we use will need to be able to connect to web services, databases, flat files, and should also be able to accept data via a tcp connection.
Is Biztalk a good solution for this, or is it is overkill?
It really depends. For the architecture you're describing, it would seem a good fit. However, you will need to validate wether biztalk can communicate whith the systems you are trying to integrate. For example; when these systems use webservices, message queues or file based communication, that may be a good fit.
When you start with biztalk, you have to be willing to invest in hardware, software, en most of all in learning to use it.
regarding your points:
1) yes, if you make sure to encapsulate the system connectors correctly
2) yes, biztalk supports this with BAM
3) yes, that would match perfectly
From what you've described (6 systems), it is definitely a good time to investigate a more formalized approach to integration, as you've no doubt found that in a point to point / direct integration approach will result in a large number of permutations / spaghetti as each new system is added.
BizTalk supports both hub and spoke, and bus type topologies (with the ESB toolkit), either of which will reduce the number of interconnects between your systems.
To add to oɔɯǝɹ:
Yes - ultimately BizTalk converts everything to XML internally and you will use either visual maps or xslt to transform between message types.
Yes. Out of the box there are a lot of WMI and Perfmon counters you can use, plus BizTalk has a SCOM management pack to monitor BizTalk's Health. For you apps, BAM (either TPE for simple monitoring, but more advanced stuff can be done with the BAM API).
Yes - BizTalk supports all the common WCF binding types, and basic SOAP web services. BizTalk's messagebox can be used as a pub / sub engine which can allow you to 'hook' other processes into messages at a later stage.
Some caveats:
. BizTalk should be used for messages (e.g. Electronic Documents across the organisation), but not for bulk data synchronisation. SSIS is a better bet for really large data transfers / data migration / data synchronisation patterns.
. As David points out, there is a steep learning curve to BizTalk and the tool itself isn't free (requiring SQL and BizTalk licenses, and usually you will want to use a monitoring tool like SCOM as well.). To fast track this, you would need to send devs on BizTalk training, or bring in a BizTalk consultant.
. Microsoft seem to be focusing on Azure Service Bus, and there is speculation that BizTalk is going merged into Azure Service Bus at some point in future. If your enterprise strategy isn't entirely Microsoft, you might also want to consider products like NServiceBus and FUSE for an ESB.
You problem is a typical enterprise problem. Companies start of building isolated applications like HR, Web, Supply Chain, Inventory, Client management etc over number of years and once they reach a point these application cannot be living alone and they need to talk to each other, typically they start some hacked solution like data migration at database level.
But very soon they realize the problems like no clear visibility, poor management, no standards etc and they create a real spaghetti. The biggest threat is applications will become dependant on one another and you lose your agility to change anything. Any change to system will require heavy testing and long release cycle.
This is the kind of problem a middleware platform like BizTalk Server will solve for you. Lot of replies in the thread focused on cost of BizTalk server (some of the cost mentioned are not correct BTW). It's not a cheap product, but if you look at the role it play in your organisation as a central middleware platform connecting all the applications together and number of non-functional benefits you get out of the box like adapters to most of the third party products like SAP, Oracle, FTP, FILE, Web Services, etc, ability to scale your platform easily, performance, long running work flows, durability, compensation logic for long running workflows, throttling your environment etc., soon the cost factor will diminish.
My recommendation will be take a look at BizTalk, if you are new then engage with local Microsoft office. Either they can help or recommend a parter who can come and analyse your situation.
I'm currently writing a large scale ASP.Net web app.
One of the thngs I can't find out about is how to justify when to use the cloud. E.g. when should I use google app engine/azure?
Also, when would I want to use bigtable over a standard dbms such as Sql Server?
Thanks
Cloud computing is all about scalability. It allows you to scale up AND scale down without having to rework your designs.
It works well for small sites, since you are only paying for resources used, but if you need to scale up, it just happens automatically (provided your application was designed for the cloud).
Also, there are theoretically much better tools in place for maintaining uptime and reliability in the cloud. For example, a system upgrade can happen without stopping your service, since the cloud computing platforms can automatically take on or off servers to service your application.
There's been a lot of talk about that from the Azure devs.
Also, there can be a financial motivation for using the cloud. Using a hosted cloud architecture can be less expensive than managing the multiple servers (DB, web, etc) that would be required for a traditional site, at least up front. As your usage goes up, the cost follows, but in theory, it can be more cost effective.
I'm not too familiar with anything else except app engine and EC2.
I'll try to add something to the previous answers:
The best thing about app engine is it's free until you attract a certain amount of users and you are charged for what your application uses, idle time is not charged.
Big table may differ from an rdbms architecturaly but from a perspective of a developer using it it's not that different.
Another good thing is python is supported. The bad thing is the standard library is crippled.
Also, you don't have full control over your data on the cloud (appengine), what I mean is you can't completely restrict the people from google from taking a peek in what you store there.
This question is very closely related to another question asked today:
"When shouldnt-you-use-a-relational-database?"
Relational databases and non-relational databases (like BigTable) address different needs. Not only in scale and performance, but in the structure and usage of the data.
The "Cloud" as I understand it is about scalability primarily. That is, the architecture refers to a capability to increase capacity in a scalable way.
Also, the Cloud is used frequently in reference to the Software-as-a-Service (SaaS) model, where someone else takes care of the servers, but that's an independent issue from the Cloud architecture. I.e. you could operate your own set of servers in a Cloud architecture.
So the justification for using the Cloud architecture is that you have an application that has a variable need for computing capacity. So it would be overkill to have N servers dedicated to match your peak level of activity. The Cloud allows you to vary your usage of the servers as your level of activity grows (and diminishes) over time.
The justification for using a SaaS model is that you don't want to be in the business of operating a data center. You're willing to relinquish some control and pay for the service, so that you can leave operation details to the experts in that technology. They handle backups, hardware failures, upgrades, 24x7 operation, etc. You handle your application and your business.
I recommend you subscribe to and read the High Scalability blog, especially some of the most visited posts such as those about the architecture of various large sites, as you will learn a lot from it that may help you make a decision. There is no hard rule as to when you should or should not use a cloud service or move from a relational database to a keyvalue system like BigTable.
One upside of cloud services in any case is that if you build your application with them, it will be immediately scalable and require much less rework later on if you require that kind of performance. However, in view of premature optimisation, it would be wise to be sure that you need that kind of scalability before you decide to build your app on such a platform.
There are several concepts to wrap your head around when using a datastore system like BigTable as well, such as not being able to just slam out writes like you would in a relational database, and having to precalculate a lot of your data rather than just doing that based on info from the database.
Although again, you can learn a lot from reading the abovementioned blog and related posts about Youtube, Plentyoffish, Google, etc.
You say you are "currently writing a large scale ASP.NET app". If you have made significant progress on it, you are already pass the point where you can justify using Google app engine or Azure. Both require significantly different architectures than you have build with a traditional application due to language support, database differences, and maturity.
Google App Engine is Python only so switching to it would require a complete rewrite
Big table is not a relational database and requires very different coding patters. SQL Data Services originally announced to be non-relational as well, but is moving to be more relational. I have not seen how close to a standard MSSQL database it currently is.
I would consider Google app engine to be a relatively immature platform so far. Database functionality is limited, you cannot run background processes, profiling and performance tuning tools are limited at best. Azure is currently in limited community preview, and so is not even available to ship a product on today.
While there are many very valid reasons to use a cloud architecture, moving to it will require significantly different architectures. Think about what effect changing that architecture (and possibly waiting for platform availability) will do to your release date.
If you are early in your project, cloud vs. not cloud is a great question to ask. If you have well on your way, I think that the importance of getting to shipping code and leveraging the work you have already put in should trump any benefits to the cloud you may see.
Something that I often run into with my users is their desire to aquire solutions quickly means that they sometimes have said "Heck, I'll just roll up my sleeves and do it in Access - it's installed on my desktop".
Sometimes, we're lucky and the person that creates the Access database back-ends it to a SQL Server, so at least the mdb file issues that often come up aren't an issue.
However, it is my opinion that rolling out an Access front-end to a SQL Server database as an enterprise solution with thousands of users, and hundreds of thousands of rows is still problematic.
What are your opinions on this? What are some of the potential pitfalls?
OR
Is this a perfectly acceptable, stable, maintainable, and robust solution?
I've worked with this scenario a great deal. In fact as a consultant/developer Access front end SQL Server back end has been a significant part of my bread and butter work over the past 10 years. Which doesn't mean I like Access ;-)
Up until the common adoption of AJAX it was a perfectly reasonable solution. And there's still vast numbers of small to medium sized applications put together in Access out there that run bespoke business systems perfectly happily and I doubt it's going to go away for the next 10 or more years - indeed Access/SQL is probably going to be the Cobol of the 21st century. If you're working on a 'green field' site then there is now virtually no excuse for deploying Access when building from scratch - but if you do inherit an existing application then the costs of a rewrite may not be worthwhile and difficult to pass with the users.
Access does have some advantages that are still significant - and can present problems if proposing to convert to a web app
It's quick. For simple CRUD work it's as fast to write and deploy as any other realistic solution.
Built-in reporting is easy to get running and remarkably powerful given the system. It's usually pretty easy to create and deploy new reports for users on demand.
It integrates well with Office. This one tends to be the show-stopper when looking to move Access apps to web-apps. It's extremely common for a 'department-size' Access application to tightly integrate with Outlook, Word or Excel - and often all three.
This is the major problem when dealing with real-world situations. It's very easy for coders to underestimate the importance of this for everyday usage of such systems and the imposition of even a small degree of additional hassle for the users will generally be met with much resistance - often enough to completely scupper the project.
If your working with a reasonable sized department - a dozen people or so - it's quite common for there to be someone in the office who fancies themselves as a bit of a computer wizard. These people can be a major pain if handled incorrectly, but equally can be a major asset. If I have such a person I will try to get management to send them on an Access course or two so they can write simple queries and reports, and set up a separate Access application for them which they own which has appropriate (restricted) access to the SQL database. You can then trust this person to handle producing simple reports and the like for their colleagues. This can be a real win-win - you gain someone who is on your side and will use you as a mentor - a ready-made advocate for you in the department - and they keep the grunt report work out of your hair. They gain a lot kudos and job satisfaction - and even a potential career path. It's far harder, well near impossible, to do this kind of thing with any other system but Access.
Main practical disadvantages
Deployment can be a nightmare. Generally if you have a very tightly defined environment - a small company, single department, citrix based or distributed with an IT department that closely controls it's PCs then you're fine. Deployment as a commercial app across multiple companies - well only if you can charge significant maintenance (been there).
Code does not scale. Access VBA code, even when written by a professional has a strong tendency to rot into rancid spagetti. It's quite common to end up with an Access application that was easy enough to maintain, but gradually becomes unmaintainable as dependencies multiply.
So I'd say Access still has a place, and it's use is defendable in many real world situations, but increasingly it's better to choose a more modern solution if circumstances permit.
We have built such a solution (Access front-end, SQL back end), with now something like 80 users, millions of rows replicated between different countries, more than 100 000 updates a month. It works fine. I think the main mistake about Access is to consider it as a tool made for amateurs to develop applications. It can work this way, but keep in mind that amateur development will give you amateur applications, while professional development will give you professional results.
A quick list of its advantages, problems and limits:
It's free for the final user, thanks to msAccess runtime
It works with the free SQLServer Express, and not so expensive SQL Server Enterprise.
It's quick, specially when dealing with forms
It communicates very easily with other Office apps, which are still enterprise standards
You can manage its interface to be so close to Office standards that using it can be very intuitive, making people happy (I talked a little bit about that on my blog, need to be updated!)
On a large scale, you have to think about the best way to distribute it to your users. This issue can turn into a nightmare, as noted by #Cruachan, but it can be solved by building and distributing msi packs for example. Such msi packs can also contain all your external references such as 'added' dll, ocx, tlb files (report dll, activeX scanner controls, etc). We had a few words on this here.
When distributing an updated version of the mdb file, you can have a common network folder holding the new mdb/zipped file that clients will check/update at startup. Your clients should have the possibility to reinstall a previous version of the mdb file. Upgrading becomes then easier than installing a new .exe file.
You have to set a version controlling system. Please check here for details.
You must be very strict on your code organisation. One of our basic rules is for example not to have any specific code at the form level. Please check here on this subject.
I didn't find any problem with VBA code scaling, as noted by #Cruachan. If professional coding rules are implemented, there will not be any unusual code scaling issue. As an example, our application is now working really fine with more than 180 different forms, and still growing without any problem.
As a conclusion, our main problem with Access is an image problem, where Microsoft still let people think that Access is here to give them the possibility to develop real sofware in 10 lessons ... and professionals, who know that is not possible, view it as a amateur tool for amateur development, looking down on ms-access users as boring low IQ red-necks.
I know quite a few professional Access developers who have developed and maintained Enterprise-level apps using Access as the front end (either MDB or ADP) and supporting user populations in the 100s (and even in a few cases, thousands).
Like any Enterprise-level application development, it requires a higher level of programming skill than building a little Access database for your 5-person department.
Oddly enough, the design principles that make for an efficient Enterprise-level app also make for a more efficient workgroup-level Access app.
I think the reason most of the people posting in this thread can't conceive of it as a good solution is simply because they've never seen it done properly, or were themselves not sympathetic to the development model that Access uses.
Yes, it's hard to do properly.
But at that level, so is every other development platform -- all of them require planning, experience and a high-level skillset.
And you can rag on Access apps developed by people without all of that (Enterprise or not), but frankly, I've encountered a boatload of non-Access database apps of all kinds that are incredibly badly implemented.
Sturgeon's law applies everywhere, and there's no reason to assume that Access development would be any different.
I started out doing desktop applications in Access with JET back-ends. I moved up to using SQL Server/MSDE with Access as the front-end and then VB6 and a smattering of classic ASP.
There are many "enterprisey" reasons to go with a "real" development tool like Visual Studio. For the scale you are inquiring about, thousands of users, I think those reasons may apply.
That said, I think there are scenarios where it still works to use Access. In my own experience, I fell back to Access with a SQL database when given a mandate to come up with an enterprise solution, albeit for a much smaller enterprise, in a very short period of time. The main reason driving my decision was time. I can put together a database UI in Access much, much faster than I can in any other tool. Some of that is familiarity with the tool, but a lot of it is that Access just gives you more database purpose-specific bits to work with out of the box. The Access UI can also be tweaked to look and operate very much like a standard WinForms app.
The hitch that many run into in an enterprise scenario is rolling Access and the application MDB/MDE out to the masses. This is easily resolved by setting it up on a Windows Terminal Server, which can also be rigged to operate almost like another app window on the client machine with the right RDP file parameters. But even that approach has its limits. I don't think it would scale into the thousands very well, but for several dozen users, I found that it worked just fine and bought enough time to meet the time constraints I had to work with so a web interface could be implemented when time allowed.
For a professional who knows what they're doing in a SQL database, an Access front end is not necessarily an unpardonable sin, especially when the mandate is cheap and fast and there isn't a religious purism involved.
If you have the choice, no.
That being said, there are situations where it may be alright. One situation is if you never ever plan on updating the access application. If it is installed for thousands of users, you may run into problems getting all of the client apps updated.
You are much better off making a web front end... Although Access makes the multiple master-detail forms easier than anything I have seen. Even Oracle Application Express, intended to compete with Access, cannot do everything that Access does.
My advice is that if you are a programmer, you can make an asp.net app that will do the same job in a much more scaleable, maintainable, nature.
For a lot of CRUD (Create Read Update Delete) work, MS Access is OK. I'm more confident in it if the data is in another engine (MSSQL/Oracle/MySQL). However, most of the time I have problems with an MS Access database it's because:
It was home grown by a desktop user (not a programmer/IT professional) and hasn't planned ahead for future development (so additions are often more painful that if a pro had been involved)
It's full of unnormalized tables, inconstancies, and key-less tables.
My solution. Limit MS Access to the pro's and deploy the runtime version to the users desktops.
For the multiple user/high data volume situation, I use Access front-ends with a MySQL back end. I must say that in the client-server situation especially on a LAN, MS Access is as good as they come. Personally, I find development in MS Access much faster than say Visual Studio especially when it comes to database driven apps. And Access reports are as good, if not better than the industry standard, Crystal Reports.
The only shortcoming I see with Access is when it comes to non-LAN situations where you have to distribute the application to users spanning a wide geographical area. But again, web apps themselves have a major shortcoming - handling of one-to-many relationships, something access superbly handles with its sub-form, sub-report feature.
And more importantly, Access has a very powerful event model that most applications cannot match.
Personally, I can literally do anything on Access! So, my conclusion is that MS Access has many advantages that make it a competent development tool especially in LAN environments.
Sadly, I have quite a bit of experience with this. We built an entire product around Access Forms tying into SQL database. Honestly, the performance wasn't an issue - it really is the normal db connection type scenarios that you'd have to be concerned about with any client/server app. In our case, the original developer knew tons of "tricks" in Access, and did things like databinding drop downs to stored procedures. Oh, and the awful triggers. Awful. As in, 45 triggers firing per update awful.
The tables we worked with did indeed have millions of rows of data, however typically the roll-out was to tens or hundreds of users. I'd imagine that any effort going out to thousands of users would benefit more from a custom development so that you can do things like build the software correctly, support it from a performance and development perspective, and build automated deployment options (MSIs or ClickOnce, for example).
So, I would not say it is a perfectly acceptable, stable, maintainable or robust solution. It worked for us because we were there to support it (and eventually rewrite it in .NET), but I wouldn't recommend it for anyone. I have, however, worked in government where trying to get anything done from "IT" (which I was part of) was so filled with red-tape and paperwork that departments would oftentimes just do the Access solutions.
Ultimately if that's the case you are in - where the departments simply can't get access to IT resources - then showing them at least some best practices for how to eventually scale the app would be helpful. As long as right after you show them, you put your resume out to find a better job.
12-15 years ago this might have been an acceptable practice (not really advisable, but acceptable) but nowadays its unforgivable. There are so many more scalable and distributable solutions that Access should be the last thing to cross somebody's mind.
When you say Access as a solution what comes to my mind is a simple, 2-3 table application that some marketing employee put together, not a real developer. If the marketing guy had a really good idea then perhaps the development team should look at it (I'm assuming there is one sense you indicated there may be thousands of users), refactor it to a better platform (intranet or winforms distributed via ClickOnce, etc), and then deploy it.
Back in the early 90s I was an Access developer--even had a MS certification. I built dozens of "Enterprise" apps (meaning 10-15 people used them). Those days are gone, IMO. There are easier solutions to build, deploy, and maintain nowadays.
I've had the misfortune to work on Access front ends like you describe, here are some non-Enterpise arguments.
Programming is easy! Creating forms in access is geared toward non-developers. Case in point, if you have multiple columns in a drop down, do you have list fields and data fields. No way! you just set he width of things you don't want to see to 0". So your looking at forms either thrown together by non-developers, or that will irk most people that have to work on them.
Versioning? Who needs versioning?, Just send out an attachment If changes need to be made to the front-end re-deployment is time consuming and fault prone.
This form, I'm thinking magenta The front end doesn't lock down well so end-users can get creative.
With Microsoft "giving away" free versions (MSDE, or SQL Express for 2005 onwards) of the SQL Server engine with each release, there is really no need to use Access any more. Although these free versions don't have a visual front end which can make development harder, good knowledge of SQL is all you need.
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.
Microsoft seems hell-bent on deprecating the swiss-army-knife of database tools. What else comes close for facading/file-swapping/cloning/name-your-acronym-connecting arbitrary database servers/spreadsheets/CSV's/flatfiles?
What weird kinds of functionality have you squeezed out of Access? And what else is there to take its place?
Access is not a DBMS. Or at least it's not just a simple DBMS. It's a very good RAD environment, a simple way to create SQL code graphically, and a regular front-end to fully fledged DBMs.
Neither SQL Server (Express or MSDE) nor Oracle, MySQL, etc. will ever replace it, until they come integrated with a simple programming language, a Crystal Reports like facility and a way for beginners to get around without having to learn SQL.
At my first professional job I developed a very big system completely in Access. Front end for the clients, admin front for me, reports and monitoring for management, permissions per user, automatic tasks run at certain times, etc. I came to learn a lot of its flaws and strengths as a result.
I've seen marvelous apps done with it, as well as pieces of crap. I still use it for personal projects, and ain't' ashamed of it (for instance, a Sudoku player, or a Karnaugh mapping implementation). There's an MVP who's created a Paint clone completely in Access, though I believe that's extreme.
Access' pearls: It's nice to easily test a database design idea and have sketch forms, reports, etc. created for you. If you change a column's name (or even a table, though that fails sometimes) it's nice to see all references to that have changed to the new name, automatically. The "sub-form" control rocks, I longed for it on VB6. And the "Thunder" button to do repeated filtering on tables is great, I wish I had something like that on SSMS!
The problem with replacing Access - and replacing Access is the problem which stops me in the vast majority of cases recommending a move to Ubuntu or SUSE desktop to my business clients - is not that Access is widely used for its database facilities: it's not except with the most Micky Mouse of user-written departmental applications which are relatively trivial to re-code. The problem is the medium sized applications where the data was migrated long ago to the corporate SQL Server.
These are a nightmare. They're often badly written (I've acquired a fair few to administer over the years) and encapsulate reams of business logic. Recoding them in anything is generally quoted at a couple of man-months at the best - usually twice or three times that, and it's unusual for a department of the size these are found in to have the budget to support that. Moreover although the arrival of AJAX and good desktop-like controls has meant that this is at least now possible in theory, in practice these are of then massively integrated with the rest of the MS Office desktop and virtually impossible to disentangle with out users seeing a drop in usability in the short to medium term - which is a show stopper in itself.
I really do not know what the solution is, apart from the slow replacement of creating new systems with other methods and hoping for the gradual demise of existing apps. Trouble is I think Access could well be the Cobol of the 1990s - it'll be around for ever supporting legacy apps because it's too costly to rewrite from scratch.
As an aside, does anyone else coming from a non-Access traditional Win32 coding background have the experience of finding that the standard of coding in even professionally written Access apps is generally below average? Although superficial (but important) stuff like formatting and variable names are generally fine I find over and over again that program structuring is poor. I know that this may often be because these apps have grown like Topsy, and VBA really isn't conducive to good coding anyway, but even allowing for these factors things generally seem worse than one might expect.
I think the easy answer is nothing... Access is commonly used because it is the only option and it is extensible. There is simply nothing else out there that is installed on nearly every business machine in the world as access is.
If you are looking for an alternative, Oracle Application Express is a fairly powerful web based app that can be run on Oracle XE. It is a potential alternative to Access but does not support Master-Detail tables as well as access.
There is a continuum of developers in the world, rather than hard and fast boundaries. People range from business managers and IT professionals. I consider myself to be an advanced amateur developer, somewhere between the two. As such I use MS Access at work to organise a large amount of data in a small architectural office including timesheets, financials and architectural specifications. Sure, the application now is a mass of stinking p** that has grown over almost five years.
I've been searching for something better than Access for ages- I can create simple apps in VB.NET however the learning curve is huge from VBA. I've looked at all sorts of options. Often you need Crystal Reports to get any kind of reporting capability, or the IDE is non-intuitive, or linking a field to a data object takes ten minutes each time, or there is not integration with other office products at all. The boss is not going to pay for something that costs a bomb, either. I'd love to get away from Access, but nothing I've looked at gets anywhere near ticking all the boxes.
the nice thing about Access is its answer to large IT bloat. It comes with MS office so its already approved for use on locked down computers but I don't have to attempt to struggle for weeks/months to get an application approved through various departments, coding hours to account for, and all the testing for an application i can whip up in an afternoon with Access. Sure SQL server would be nice to use, but not worth the headache.
I doubt Microsoft will kill off Access. With Access 2007's integration with Sharepoint and the rapid growth of SharePoint, Access may in fact have a resurgence as an off-line and reporting tool for SharePoint web sites.
I don't think MS has any intention whatsoever of getting rid of Access. They may transform it into more of an end-user tool than a programmer's tool, but it is never going away. The forking of the Jet database engine into the traditional Jet 4 version that ships with every copy of Windows (because Active Directory uses Jet 4 as its data store) and the version that is owned by the Access development group (the ACE, with its ACCDB file format, which is, de facto, Jet 4.5 or maybe Jet 5).
Access is a hugely popular and useful application and functions in a whole host of levels within any number of organizations, large and small.
Why is there no open-source alternative to Access?
Because it's way too hard to create such a complex piece of software that does so many different things well.
My cousin is a serious FileMaker guy. He seems to be doing great and has grown a small firm around it. Apparently FileMaker is a cross-platform Mac/PC system for rapid app development...
Maybe something like that will rise up with the business power-user/RAD set?
Microsoft may have a history of intentionally killing off database systems like this. I listened to a .Net Rocks interview one time with Les Pinter, where he claimed that he once heard a top Microsoft exec say that every copy of FoxPro that sells costs Microsoft thousands in lost SQL royalties. And where is FoxPro today? Officially, it is was end-of-lifed in March of 2007. So how did it get from prominance to demise? Well, Les says that Microsoft acquired it and ran it into the ground on purpose.
I am not usually big on conspiracy theories, but this does resonate with Microsoft's track record from that era.
Anyway, trivia aside, I believe there will be more RAD-style database tools... They empower non-developers and allow developers to solve certain types of problems very quickly. I have an aversion to using them for large projects that, unfortunately, cascades - small projects tend to grow over time. So as a result I only use them for the very tinest things.
As for the long term consequences... Well, I have seen scenarios where they didn't scale well and all those fragmented solutions started to look a lot like technical debt. It is actually possible to hook Access up to a SQL Server back-end, which solves a lot of problems.
Probably the biggest/weirdest thing I did with Access was writing an EDI system from scratch. For those of you who have worked first-hand with EDI, you know what I'm talking about. What a silly idea that was. My problems here had more to do with VBA than Access though -- I remember just really needing interfaces and not having them.
I also used it for code generation back before things like Codesmith were available. It generated business objects (CRUD and some other basics) for ASP Classic. That actually worked awesome.
in my experience Excel is even more widely used inside corps. We're just now doing a project where we convert ~ 60 000 Excel documents (with 4-12 sheets in each) to Sharepoint and Infopath forms. ;)
Microsoft would like us to move to using Office Business Applications - essentially hooking up the office apps to databases. Add SharePoint into the mix and there is a lot of possibility. Also plenty of licencing fees for MS as well.
I have seen access used to integrate and front end GIS and health data. It blew me away how well this app was coded and documented.
As Mark. Access was my first approach of database and I found it powerful at the time. It has some nice features like generating SQL from "query by example". Its form features and capability to print on various format (sheet of labels for example) was nice too.
On the downside, it is proprietary, and each new version was incompatible with the previous one: if you load a base made with Access 97 with Access 2000, you can no longer load it with the older one...
Although I don't do much personal database works (list of addresses, mostly), for such work I would use either Open Office's database tool (not tried yet) or a good old open source database (MySQL, SQLite come to mind as lightweight bases) with a GUI front end, for example, SQuirreL SQL Client, and probably JasperReport as report front end.
Not as integrated as Access and with steeper learning curve, but somehow more flexible.
Now, I am sure we can find some simple good old non-relational database for the simplistic uses I had at the time. :-)
I welcome the day when Access breathes it last breath and joins the likes of Clippy.
Access is well-intentioned, but it has become a crutch. Even in large companies with able IT staffs, Access applications can run rampant, providing a pain point for knowing the global landscape when it comes to products to maintain. Linked Access databases that point at other datasources, unmaintained Access applications, and just shear flexibility are issues, in my opinion.
I think that Access is actually too powerful, too flexible, and too extensible for its own good. In Microsoft's well-intentioned attempt to bring rapid development to the desktop database realm, it really has opened a Pandora's box. Look at it from another perspective, too. Assume that a company has a few applications that are written in Access. The developer who wrote them leaves. These applications are just important enough that they still need to be used, but not important enough that IT gets the approval to port them to a more technologically capable platform.
Now, the situation is that if no one on the team knows Access, it is requirement for the new developer. This means that you might have to pass on a developer who is the most technically well-rounded and the best fit if he does not have legacy chops. I speak from experience, on this. We are down to two legacy Access applications, and are trying feverishly to convince of the needs to either incorporate the functionality into related, code-based projects or into new projects of their own. I have one developer with Access "chops", and am not going to base a candidate search on whether someone knows Access or not in the event that he leaves.
As far as the weirdest thing I've seen squeezed into Access...
I am a police dispatcher for a smaller university, and we (like almost every agency) use a CAD (computer aided dispatch) and RMS (record management system) system.
Our previous CAD/RMS software was built ENTIRELY into Access. You opened Access, and through an ugly GUI, entered calls for service, everything. Officers wrote reports through the same interface.
It worked great at first, and then as the database size grew, it became extremely slow and difficult to use. This is what happens when the state makes you go with the lowest bidder on a project...
Now we use a CAD/RMS solution that is browser-based, backed by MS SQL.
I don't think that Access is going away anytime soon. The beta of office 2010 is out with an updated Access included and the Microsoft blogs are hyping the features of Access 14 (the version after 2010) which include improved Access Projects (.ADPs) with better support for SQL Server 2005/2008 and better .Net integration.
If i were to look for a new integrated database development system providing front and backend features Oracle APEX would be the main contender. Front ends are web based requiring no runtime on the client, the whole system is free to download and instal (express edition) and given a few years the entrance barrier for new users hopefully will be reduced so it is something laymen can dabble in.
Access is just migrating to more of either a single user on a desktop or a few users on a shared database file without much security. If you want to take it to a slightly higher level, use Access as a frontend to SQL Server.
Well now it seems Access 2010 is looking to get the hooks into SharePoint in an attempt to "web enable" the Access application. There are even host sites catering to this technology. Maybe all those who were concerned Access couldn't scale can fear no more?
Access definitely has both pro's and cons, it's just another tool to use but not abuse. Every adult job I've ever had used ran on windows, so Access or something like it will exist. I feel sorry for the places that are stuck in Access quicksand or lost in excel hell. But are we forgetting that all that can be corrected and better yet prevented with a bad ass bi team and proper training.
PostgreSQL, MySQL, FileMaker, <insert name of database that is not Access here>, Excel, custom parsers, natural language importers, Perl just because it is a swiss army knife, grep awk sed, m4, the old versions of Access before the demise of Access, ...
weird functionality? Rather than the normal myriad of ways to access Access, I use SQL statements to access Access. The SQL statements that I use work with other databases as well as Access -- weird I know.
Like many, I have used and abused access over the years, always felt a little dirty though ... I felt a little better about it when I came across this post by Rob Conery recently:
http://blog.wekeroad.com/blog/hacking-your-vote/
Would never have dreamed of using access in a voting system. Scary.
FileMaker is a good database for shifting from MS Access.
It is a cross-platform database (mac/PC). It has a Web Viewer, through which you can connect to the web world. For example, charts, maps etc can be shown in this web viewer.
FileMaker is easy to use for beginners. You could also explore the scripting mechanism and achieve data manipulation.
The latest FileMaker 10 has several new interesting features. My vote is for FileMaker.
I believe File Maker Pro will probably become a new standard if people ever figure out it exists.
FMP has all of same features / short comings of Access plus you can actually make a real client / server setup if you know what you're doing.
In a single file you can define your forms, reports, tables, etc. It is also cross platform and runs on Windows or Mac, and can be adapted to web based too. All by design.
Coming from the "real" SQL servers to File Maker Pro was really hard mentally but once I got the hang of it I found it was pretty amazing. Now as a database it's nothing special but as a database application development system that "normal" people can use it really shines.
If you PLAN on a network setup I would suggest taking the time to learn how to separate the storage database from the application database up front. Otherwise upgrades require you do lots of data export / import and that can take a while or be almost impossible if your tables change significantly.
I've built a call center application that automatically handled incoming phone number lookup and automatically dialed regular POTS phones using FMP on NT. That was about 6 years ago so I imagine it's improved since then.
I've only used Access when I wished Excel could do a "Left Inner Join". Otherwise a MS has done a fair job making there C#/SQL offering simple (and free) to use for light weight RDB projects.