Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Why FM is not wellkmown in the world as the good database tool?


aaa
 Share

Recommended Posts

I think, that this section is the nearest for my question.

I worked with Access in 1996-1999.(i dont speake about early tools as Dbase,Foxbase, Foxpluss, Clipper)

Now i dont remember it, and also dont want.I remember only one: anything to do in Access was difficult and takes many times. I tried to learn VB after FM, but didn't like it. I learned SQL SERVER 2000. It is good database tool, but very hard and big. There is not reason use it in middle business.

But here i want to open thread "Why FM is not wellkmown in the world as the good database tool?"

Link to comment
Share on other sites

I often wonder that myself. To many database geeks, FileMaker seems to have become the AOL of the database world: something to sneer at, to deride as too babyish and in some fashion lacking the tough gears of a "real database environment".

 

Now, to a limited extent, the "big iron" systems like Oracle and the various flavors of SQL do make FileMaker look like something that's "not enough to do the job" — if the job in question involves hundreds of millions of records, or thousands of concurrent users doing simultaneous intensive searches and sorts. You would not want to try to run the Social Security Administration of the United States on FileMaker (visualize a table with one record for every pay stub for every person, dead or alive, who has ever paid social security taxes, with related tables for everyone who has ever employed anyone and for everyone who has ever been employed. Then figure several thousand SSA employees accessing the data simultaneously and running reports).

 

But 99% of the time, the loudmouths ragging on FileMaker are talking about the usefulness of a database for one user on their own desktop, or for a small or medium-sized business. And data sets nowhere near that size. Database demands, in other words, right in the zone where FileMaker shines.

 

They also say FileMaker is "slow". And it's true that the "big iron" systems can process queries (especially across multiple tables, or as we would say in Filemaker-land, searches on related fields, therefore unindexed) a lot faster. Again, this mostly comes back to file size: FileMaker isn't designed to manage millions of records, but if you're working with tens of thousands it's fast enough, and it's robust at several hundreds of thousands of records if you pay close attention to how you write search and reporting scripts so as to minimize FileMaker's weaknesses on related-field searches.

 

 

Some of the not-so-big-iron competition can do faster searches, too. FileMaker is disk-based, meaning that, like Photoshop, it writes scratch files and pages out most of what is being worked on, only reading fragments into RAM. At the smaller end of things, filesize-wise, some database products (4D for example) attempt to read the whole database into RAM, which speeds up data manipulation considerably. Of course, once you go beyond a certain point, the OS itself is just going to make its own decisions about paging out chunks of the application's allocated memory space anyhow, and no database system that runs on a workstation-class computer can run a database as large as FileMaker's upper limits truly in RAM. Meanwhile, stick a blisteringly fast hard drive into the picture and hard drive access speed becomes less of a bottleneck than network latency and throughput in most cases anyhow.

 

Meanwhile, the "big iron" systems are not a unified environment like FileMaker. You design the rows and columns (field definitions, to us) and set up relationships between tables in an "RDBMS". Then you create the environment that the end users rely upon — the GUI (layouts, to us) and the execution elements that perform actions (scripts and button-functions, to us) in a totally different software environment such as Brio or Crystal Reports. Simple stuff that we take for granted — the ability to go Command-F / Control-F and do a Find on any fields from any layout that has fields on it — all has to be hand-coded in the "reports" software. To write a routine that would give you what you get for free with Command-F / Control-F (including multiple requests, "omit" requests, the ability to view your own consecutive requests in Find Mode, the ability to draw upon the same drop-down value lists you get in Browse Mode, even including related values —*utilizing a relationship between a value entered in Find Mode in the current table and a value in the actual dataset in a related table...) would be a massively intensive chore.

 

Furthermore, the environment that the end users work in doesn't, strictly speaking, "contain" the live data. The "front end" software has to fetch the record set via a SQL Query (a Find, in other words), and the relevant data is copied to the local system to be manipulated within the reporting software's environment. To edit, data has to be sent back upstream to the "big iron" table-structure after being edited locally within the "reports" environment.

 

Because of the messiness and complexity that it would involve to write an all-purpose "front end" for a "big iron" solution, it's commonplace for solutions developers to write one front end for data entry (or even a separate front end for data entry of each table, or for 2-3 closely affiliated tables apiece), and another front end for searching and running simple "reports" (mostly just list views of found sets or subsummary reports with subtotals of the found set), again often constructing different front ends for searching on these seventeen fields + running any of 7 relevant reports and for searching instead on these other twenty fields in this other table + running any of these 4 reports, etc.

 

Changes that are nearly effortless in FileMaker, like changing a field name or creating a new field and including it in a report, are a real tooth-puller in these "big iron" systems. Kick everyone out. Change the actual table in the RDBMS. (In some cases, even this part isn't simple). Then open every one of the Brio / Crystal Reports / whatever "front end" systems and make the corresponding changes. And it gets worse from there.

 

So stuff that in Oracle or SQL means downtime and making out advance plans for "implementation strategies" and "backout plans" for reversing course if something goes wrong, is stuff that in FileMaker you say to the person on the telephone making the request: "Like that?" And you've done it and the change appears on their screen and they don't even have to log out for you to make the change.

 

Most other database systems (including Access, 4D, Servoy, and other not-so-big-iron competitors as well as SQL and Oracle et al) are really rigid about how they'll let you associate two tables. You can look at a million relationship diagrams from these other environments and never see multiple table occurrences of a single table, never see multiple ways for Table A to connect to Table B, never see a text field over here connected to a number field over there. Most of them demand that you anoint one field per table as a "Primary Key", which must be unique and not empty, and the conventional design strategy is to only join table together via their primary keys. Our FileMaker relationship diagrams may look like your kid sister's Cat's Cradle, but we aren't afraid to put our fingers in. If we find it useful to have a global text field in Table A and populate it with a series of number separated by hard returns and then relate it to a number field in Table B, we can do it, and we see the rigidity of the other systems as severe limitations on what you can do with a set of data.

 

NOTHING is as flexible, easy, user-friendly, and as powerful in the sense of being able to DO for you pretty much whatever you can conceive of wanting a database to do for you, as FileMaker is.

 

Frankly, I think what drives a lot of it is the IT-Department attitude. It takes great skill and hard work to make an Oracle database meet the needs of the people that use it, and to troubleshoot problems. They had to take courses specifically in database design to master it, and they have geeky little debates about

 

So here's this software product that people whose skill sets need not exceed those of the end users that they call "LUsers" can use to make functioning databases. Well, it has to be a toy, then, doesn't it?

Link to comment
Share on other sites

Hi, AHunter!

Thank you for full answer.

"They also say FileMaker is "slow"."

...I am not agree, because in last time i tried to compare the speed of FM and SQL. I tried it for 500 000 records.

In this file FM and SQL finds records in the same time. But after find, if you want go to last record of findset, FM does it imideatly, but for SQL it takes advanced time.

Also i tried to compare sorting speed. How i remember here on the large file SQL is little faster(for 500 000 records). But in the practic life i think there is not reason to sort so large file(for what?, if you quickly can find neccessary records then sort).

"NOTHING is as flexible, easy, user-friendly, and as powerful in the sense of being able to DO for you pretty much whatever you can conceive of wanting a database to do for you, as FileMaker is."

Yes it is. And i want to include FM is faster for developing.

Conversation:

-Let create database for university!

-Let create.

-We must use SQL and C++ or VB!

-But why this tools, if there is faster and easy tool to do it as FM?

-Because all people uses SQL.(strikingly)

And this is the main reason.

For 10000 records maximum they uses SQL, then uses C++ or VB for creating client side programms.(because all people uses SQL).

Excuse me for my english.

Thank you once more AHunter.

Link to comment
Share on other sites

  • 2 weeks later...

Well I'm only about a week into using FMpro and it doesn't seem like there is much control over presentation and I don't like that. Not to mention terrible handling of media files. In particular, movies, a problem I've been trying to work around for the past week. It seems like the generic "container" field is limited in a number of ways such as display over the web and in the ability to export data. Feel free to correct me if I'm wrong.

Link to comment
Share on other sites

Can you elaborate on "presentation"?

 

re: media files on the web, FileMaker is only now getting decent IWP. (IWP in versions 4-6 sucked pretty bad). You'd probably find better results if you store the media files on a web-accessible server, and reference them with Open URL scripts wtihin FileMaker, rather than embedding them in container fields.

 

In my defense of FileMaker, I was thinking in terms of its native deployment. I would no longer say FileMaker sucks when accessed via web, but I'm not quite ready to say it's the best thing out there for web-based database access. Certainly there are methods of accessing some databases some of the time that don't work particularly well with FileMaker (I would not, for example, expect that someone would write a Brio module and query FileMaker via ODBC for all end-user activity and then report back that FileMaker works every bit as well as Oracle for that). The web is a secondary means of accessing FileMaker data.

Link to comment
Share on other sites

What I meant by presentation was web presentation... it would be great if you could embed some html and even some CSS to control styling, but I can see that that is not its primary use. If I could somehow get into and edit the default html that is used to display media inside of containers, I could solve my problem pretty easily, but I can see no way to do that.

 

The thing is, if as you say the web is a secondary means of accessing filemaker data, it requires a license for every user which can become expensive. Nor should a full license be necessary if all you want to the other users to be able to do, such as we do, is see the data and not edit it.

Link to comment
Share on other sites

yeah ...once upon a time (FileMaker Pro Binder 3.0 era) you could create a freely distributable runtime engine for a networked solution. It was read-only (in the sense that you could not use the runtime to edit database structure, not in the sense that you could not create, delete, or edit records themselves).

 

Depending on your viewpoint, FileMaker Inc either decided to stop the financial hemorrhaging or become unconscionably greedy, but either way changed the runtime so that it would no longer open networked solutions. (FileMaker Binder 4 and FileMaker Developer Tool 5 thru 6 were still free to distribute and would still open local copies of bound solutions, but networking capabilities was ripped out).

 

I am ignorant, being in what is still a FileMaker-6 shop and having not as of yet shelled out for FileMaker Advanced, about what features are available to runtime-engine-powered database solutions these days. The FileMaker web site says something about them supporting some web features, but that may be simply the 8.5ish ability to display web-URL content within FileMaker, and the runtime engines may still totally lack network-client capabilities — is that correct?

 

Anyway, some folks within the developer community have been saying "thin client, please" for years now. Others point out that for large deployments there are reasonble site license prices, and for small deployments the total cost of development + deployment is still cheaper with FileMaker than with architectures where development is the nasty piece of work I described in my long post above. The reason there's a market for $30,000 off-the-shelf shrink-wrapped one-size-fits-all corporate database solutions is that it would cost small companies more than that to fully plan out, develop, and bug-fix a custom solution in PowerBuilder, FreezerWorks, Oracle, etc etc. And FileMaker is very competitively priced to go up against that, even given the necessity of paying for a client-seat copy of FileMaker Pro for each end user's workstation.

Link to comment
Share on other sites

it would be great if you could embed some html and even some CSS to control styling

 

I believe that's what Custom Web Publishing is all about. And users accessing the DB via their browser are not required to have any kind of license.

 

Moreover, if all you want is to present the data, without the possibility to modify it, you can do this very inexpensively by exporting your data as XML, with an associated XSLT stylesheet to produce your HTML pages. A plain version of Filemaker can do this. True, your visitors will only see the last-exported data, but a periodical export can take care of that in most cases.

Link to comment
Share on other sites

Just to confirm Runtimes created in 8.5 can still not be used as shared files.

 

You may be right, you may be wrong, depending on how you read that.

 

To be clear, the runtime engine is not networkable. The runtime engine cannot access files hosted on FileMaker Server.

 

The runtime files themselves however can be hosted on a FileMaker Server and accessed by FileMaker Pro clients.

Link to comment
Share on other sites

David,

 

Thank you for expanding on my point. I wonder, could you clarify a little further.

 

You said:-

The runtime files themselves however can be hosted on a FileMaker Server and accessed by FileMaker Pro clients.

 

 

 

Does that mean that runtime files if hosted on FMserver and accessed by FM clients will act just like a normal file and can be accessed by more than one user at once or would the nature of the runtime file restrict the use to one user at a time?

 

Regards

Phil

Link to comment
Share on other sites

Does that mean that runtime files if hosted on FMserver and accessed by FM clients will act just like a normal file and can be accessed by more than one user at once

That is indeed the case.

 

In order for the database files which are associated (bound) with a runtime to be opened and shared using FileMaker Server (or Server Advanced), the file extension must first be registered in the configuration panel of FMS. Once that is done, the runtime data files can be shared or web published via FMS in the same way as regular FMP databases.

 

They cannot, however, be opened with the runtime application whilst being shared in this way.

Link to comment
Share on other sites

I believe that's what Custom Web Publishing is all about. And users accessing the DB via their browser are not required to have any kind of license.

 

Moreover, if all you want is to present the data, without the possibility to modify it, you can do this very inexpensively by exporting your data as XML, with an associated XSLT stylesheet to produce your HTML pages. A plain version of Filemaker can do this. True, your visitors will only see the last-exported data, but a periodical export can take care of that in most cases.

I don't know if Custom Web Publishing is something different from Instant Web Publishing that is with FMpro... but Instant Web Publishing doesn't give you any of those controls. And my first thought to get around my problem (re: my other post http://filemakertoday.com/com/showthread.php?t=10517) was to export the database to HTML. Unfortunately you can't export the contents of container fields. So I also tried implanting some html in a text field, but HTML characters are parsed into entities, so it only renders as text.

Link to comment
Share on other sites

a) Custom web publishing includes the use of middleware and external protocols. The modern FM world now speaks a bit of PHP, the older FM world knew of CDML. Middleware-wise, there was Tango and there was Lasso, either of which would allow you to display container-field data (among other things), to run scripted routines that existed only in the Tango (or Lasso) environment, or to call actual FileMaker scripts (generally not done as much , at least in the FileMaker 6-and-earlier days because the host would be running FileMaker Pro not Server, therefore single-threaded).

 

As with the rest of FileMaker-on-web, the possibilities for above-and-beyond-IWP are a lot better now than they used to be. The PHP thing strikes me as a spectacularly rich set of possibilities (although I, unfortunately, don't speak a single symbol's worth of it and would have to learn new tricks).

Link to comment
Share on other sites

I don't know if Custom Web Publishing is something different from Instant Web Publishing

Custom Web Publishing is definitely different from Instant Web Publishing. IIUC, in the current version you need Filemaker Server Advanced in order to take advantage of CWP.

 

Unfortunately you can't export the contents of container fields.

No, but you CAN export URL's pointing to the contents.

 

my first thought to get around my problem ... was to export the database to HTML.

Exporting as HTML table is very limited. Exporting as XML is a very powerful tool - and not an easy one, I should add. Nevertheless, it sounds like this would address your concerns perfectly. There are some basic examples included with the application, and more on FMI's site.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use