Glad to see several others chiming in while I was away.
We seem to be overlooking one important factor about Filemaker. It was originally designed and invented for use on an Apple.
This is the main reason (I think) why it does not have VBA available. VBA doesn't work on an Apple.
There have certainly been enough Windows versions of Filemaker released that VBA could have been incorporated into it if the makers so choose. That they have chosen not to seems to me to be a devotion to the original (Apple) configuration. If VBA were available on the Windows version, they would have to come up with somthing similar for the Apple version, which means taking the whole project back to the drawing board.
As dfenton points out- VBA is in fact available on Mac. What should even be more telling is the fact that for Office 2008, they dropped VBA citing several good reasons for doing so though ultimately it was shortsighted move. Now, the Office 2011 is slated to have VBA back. Personally, I think this is just another mistake as they're bringing back legacy technology when they should be moving ahead to VSTA & .NET functionality as well providing a compatibility layer for the existing VBA macros. But my whole point here is that even on Mac, there are investment in VBA that there was big enough outcry that forced Microsoft to reverse their earlier decision of scrapping VBA from Office 2008.
And dfenton's right- it's really not about VBA but rather the lack of a formal scripting languages. Access at least gives us both macros and VBA. Filemaker only gives us scripts (e.g. Access's macros).
Now, to be honest, I don't have any facts but from what I see all over, I'm inclined to believe that people at FM has decided to put more emphasis on usability than power and thus did more than Access to hide the actual complexity. Did they succeed? Well, I can tell you it's easier to get off and designing something in few minutes but the ceiling is pretty low. With Access, there's lot of disparate objects requiring the novices to at least grasp the concept of tables, queries and forms before designing can even start in earnest. So in that respect, FM has succeeded, yes, but as soon as the same user says, "Okay, now I want to embed my business logic..."
We can then turn to the table-level validation or macros to provide rudimentary validation. Good so far, and both are on par. Now if it's complex formula and the macros doesn't support it... it's VBA for Access. For FM, it's now plug-ins which you have to pay out money for.
Mind, a case can be made that it's cheaper for a company with no programmer to just buy a pre-packaged plugin to extend FM than waiting months for their receptionist to learn the basic VBA and 'get it' before writing out a solution. It's a classic question of time versus money. Either will definitely be cheaper than hiring a contractor to develop a custom solution, definitely, but that's a decision that everyone in charge has to come face with.
Perhaps I have become cynical but I wonder if those earlier posts were nothing but entrees to the main course which was always intended to promote Filemaker Pro to Access users. "What is the best" is a classic spamming technique used in forums. Though not in this case, it is usually accompanied by a "second user" who promotes the target product.
Unfortunately for FileMaker, the responses in this thread will have had exactly the opposite effect. Anyone reading this thread would be unlikely to even bother looking at FileMaker.
IMHO, a good argument for not choosing FM can be found from FM's own site:
Filemaker and Access comparsion.
Now the author has spoke about Access in a disparaging manner but if you're astute reader who can read between the lines, the author has made several concessions where Access is ahead or on par with FM.
Take a look at the history of posts by the OP of this thread (genesis).
I do certainly hope that this isn't a case of spamming/advertising, but even so, I think we have to go back and look at what design consideration were at play for each products. With FM, as stated above, I'm inclined to believe that they want to have a usable product for people who are not programmers. Access attempts to does the same thing, but I've always perceived Access as having more of IDE feel than a "appliance" feel. Not a bad thing, mind, but that's something we have to take in consideration. One of my long-standing beef is that there's a persistent belief that's quite widespread and isn't limited to just Filemaker or Access: That we must dumb down to make it simple. That is not true. Access's recent addition of multi-valued fields and lookup fields are one example. So is FM's hiding the normalization. VBA's too lenient with undeclared variable by default. All share in the common in that they teach bad habits and thus makes a bigger mess when the time comes to advance into next stage of evolution. This is, IMHO, a big reason why so many IT people dislike Access, dismissing it as 'toy database'. They never realized it was the carpenter, not the hammer that is inept. Same attitude can be found towards MySQL, yet it became popular because it was simple in contrast to many other RDBMS. Then we have Access exposing the full complexity when we toggle between design view to SQL view. So it is possible but for whatever reasons, it is not implemented consistently, even within the same application in question.
And when nobody would bite on that one we get this thread which incredibly labours the point of the 7TB capacity, the supposedly superior security, and simple connectivity of FilemakerPro over Access.
...
And genesis promotes that FileMaker security is simple while Access is diabolically complex.
I must have had got caught up on the size because I missed the security. That said, I usually like to tell others that the problem #1 with security is that it's far easier to fool oneself into thinking it secured when in fact it's not secured.
I was wondering what the whole purpose of the tenacity of the OP was. If it were a company sending out evangelists, I would have expected something a lot more articulate and well though out. Either way, the OP should do a little more research on Access and SQL Server before saying it does or does not do a certain task.
The problem is finding someone who knows enough about Access to be articulate and yet still wants to back FileMaker.
Or he could just be a novice wanting to eat his cake and have it. I'm probably being a Pollyanna, but then again, it's not exactly the first time this kind of thread popped up. A while ago, we had a poster complaining that he could do his queries in 4GL and that SQL was clumsy compared to it, because he could put syntax in any place and it'd just work. Then there's some people who want to use it for web applications but don't want to learn ASP.NET or Java or whatever.
Oh, well.
Or he could just be an Apple snob.
I did contemplate this possibility but elected not to suggest it. But now you mention it.
It would certainly account fo a lot of the persistence. Mac users frequently are particularly vocal about the superiority of their computers and software in an effort to overcome the sneaking suspicion that they have paid top dollar for a machine with limited capability. The inability to run Access is a glaring shortcoming for which there is no comparable substitute.
You'll have to forgive me for not wearing my beret and speaking in snotty French accent everytime I post. I'll try harder to fit the stereotype next time.
Oh, BTW, use Fowlmaker pro! (LOL, jk).
Nah, Tyson has it already. Crazy licensing fees, so they say.
