"The problem is business can not rely or depends on a tools that that dont know if it would still exist in 5 years."
FileMaker Inc. has made a profit for EVERY year of its existence; it has millions of users, has a growing user base, has a large network of professional designers all over the world.
The person who made the comment above talked about SalesForce as a better alternative; to begin with, SalesForce hasn't been around for 30 years.
Agreed. Don't know why anyone would doubt the continued existence of a product that's been around so long and keeps getting updated so regularly(too fast for my taste.) Filemaker is very powerful. I sometimes use scripting and calculations to do text manipulation that I am not skillful enough to do with Perl or something else.
I've used Filemaker since 2.1 in the early 90's taking advantage of the fact it could handle Cyrillic and Japanese. I think the relational stuff came along more mid-late 90's but even with the earlier versions you could fake some things with look ups.
My main complaint is that for the non-developer, the "layout" user interface has gotten pretty difficult. It used to be much easier to use.
Well, I like Filemaker because I can actually use it to do complicated things that I personally could never accomplish on the other Databases. It continues to grow and get better. Cross Platform: Yes. Access Users would not like because it is a lot simpler to produce a finished solution. If is not a transactional database like Oracle. Well kept Apple Secret.
LARRYJW said this: "In FileMaker it's impossible to actually build an application in which the tables are true relations (which is what it means to be a relational database: table == relation)." That is pure nonsense, and he clearly has no experience with FileMaker; I have solutions with over 100 related tables in them; one can either put all the tables into a single database file, or have them spread among multiple files. In either case, the tables can be as relational as one might wish. The tables don't have "common fields;" the design schema allows the user to relate tables just as one would with SQL. LARRYJW needs to look at it before he makes incorrect assertions.
In fact, FileMaker also has the ability to use SQL queries for finding and using data. For the record, FileMaker became fully relational back in the early 90s.
Thank you longterm for proving my point. Relational databases are NOT relational because you can "relate" tables. In the language that is just a JOIN (inner join, left outer join, right outer join, full outer join, natural join, semi-join). The ability to JOIN tables is NOT what makes a database a Relational Database. In the almost 50 years since Codd wrote his seminal paper, hundreds of books, most accurate, have been written about this topic -- clearly, none of which you have read or understood. Many books are simply wrong since too many in the field simply want to make a buck and since Relational Databases became the marketing word of choice, every database in existence was marketed as Relational regardless of whether it was or not. This is too much the American Way -- fake it.
To be a relational database, the things generally called Tables must be Relations. Relations are a general mathematical concept. For each table is a set of rows, and the columns are set of functions of the columns which are the KEY to each function (each column) of the table. In no way does FileMaker implement the Relations and in fact, my experience with FileMaker is that it is impossible to implement Relations in FileMaker when implementing any application.
Most tables in Filemaker must contain fields which not functions of the supposed key of that table. Summary fields are typical examples. Global fields are another. They're values are not a function of the key of the row in which they exist. This is big deal and not some exercise in academic trivia.
Further even Oracle XE is more than a capable database server out of the box, and you don't have to spend a bundle buying a Filemaker Server -- overpriced and underperformance at any price.
Critically, Filemaker does not see the "database" as independent of the reports. If the table takes part in multiple reports, then it is typical that the table has multiple fields which are created for the multiple reports it belongs to.
As I said, the best freely accessible database is Oracle XE. It definitely has limitations over its enterprise version -- only uses one cpu, limited to 11GB of data, and true of all Oracle databases, to my chagrin, Oracle does not support large text fields or containers as relational database fields (in a formal transparent way) unlike its trivially easy-to-use versions in FileMaker, Access, MySQL (though Apex now handles these kinds of fields easily). But, like its enterprise versions, Oracle XE databases also support the very complete procedural programming language PL/SQL which at all levels blows every other database application system out of the water, especially Filemaker and even Access with in Basic language. Oracle also supports the Java language within the database (which it did long before Oracle bought Sun).
A whole lot of nonsense in this article and in these comments. I built a FileMaker application for a multibillion dollar company that pushed 100 million kg ( think tons if you're American ) of cargo per/year into Afghanistan in support of the US military; flight operations, cargo build up, manifesting and warehouse management. I had no team, just me from my cargo container in Afghanistan. 24+ Boeing 747s a week plus. A single failure and I was out of a job. Not that IT was my job, i built the entire application on the side, over the objections of our massive IT department and it resulted in the termination of their team built aviation application. FileMaker has come a long way since my first application 20 years ago while I was in Art & Design college; I've only built 3 solutions. My latest application performs a similar role in Iraq, Afghanistan, Africa.
LARRYJW said this: "In FileMaker it's impossible to actually build an application in which the tables are true relations (which is what it means to be a relational database: table == relation)." That is pure nonsense, and he clearly has no experience with FileMaker; I have solutions with over 100 related tables in them; one can either put all the tables into a single database file, or have them spread among multiple files. In either case, the tables can be as relational as one might wish. The tables don't have "common fields;" the design schema allows the user to relate tables just as one would with SQL. LARRYJW needs to look at it before he makes incorrect assertions.
In fact, FileMaker also has the ability to use SQL queries for finding and using data. For the record, FileMaker became fully relational back in the early 90s.
Thank you longterm for proving my point. Relational databases are NOT relational because you can "relate" tables. In the language that is just a JOIN (inner join, left outer join, right outer join, full outer join, natural join, semi-join). The ability to JOIN tables is NOT what makes a database a Relational Database. In the almost 50 years since Codd wrote his seminal paper, hundreds of books, most accurate, have been written about this topic -- clearly, none of which you have read or understood. Many books are simply wrong since too many in the field simply want to make a buck and since Relational Databases became the marketing word of choice, every database in existence was marketed as Relational regardless of whether it was or not. This is too much the American Way -- fake it.
To be a relational database, the things generally called Tables must be Relations. Relations are a general mathematical concept. For each table is a set of rows, and the columns are set of functions of the columns which are the KEY to each function (each column) of the table. In no way does FileMaker implement the Relations and in fact, my experience with FileMaker is that it is impossible to implement Relations in FileMaker when implementing any application.
Most tables in Filemaker must contain fields which not functions of the supposed key of that table. Summary fields are typical examples. Global fields are another. They're values are not a function of the key of the row in which they exist. This is big deal and not some exercise in academic trivia.
Further even Oracle XE is more than a capable database server out of the box, and you don't have to spend a bundle buying a Filemaker Server -- overpriced and underperformance at any price.
Critically, Filemaker does not see the "database" as independent of the reports. If the table takes part in multiple reports, then it is typical that the table has multiple fields which are created for the multiple reports it belongs to.
As I said, the best freely accessible database is Oracle XE. It definitely has limitations over its enterprise version -- only uses one cpu, limited to 11GB of data, and true of all Oracle databases, to my chagrin, Oracle does not support large text fields or containers as relational database fields (in a formal transparent way) unlike its trivially easy-to-use versions in FileMaker, Access, MySQL (though Apex now handles these kinds of fields easily). But, like its enterprise versions, Oracle XE databases also support the very complete procedural programming language PL/SQL which at all levels blows every other database application system out of the water, especially Filemaker and even Access with in Basic language. Oracle also supports the Java language within the database (which it did long before Oracle bought Sun).
Thanks for the lecture but results are what matters.
LARRYJW said this: "In FileMaker it's impossible to actually build an application in which the tables are true relations (which is what it means to be a relational database: table == relation)." That is pure nonsense, and he clearly has no experience with FileMaker; I have solutions with over 100 related tables in them; one can either put all the tables into a single database file, or have them spread among multiple files. In either case, the tables can be as relational as one might wish. The tables don't have "common fields;" the design schema allows the user to relate tables just as one would with SQL. LARRYJW needs to look at it before he makes incorrect assertions.
In fact, FileMaker also has the ability to use SQL queries for finding and using data. For the record, FileMaker became fully relational back in the early 90s.
Thank you longterm for proving my point. Relational databases are NOT relational because you can "relate" tables. In the language that is just a JOIN (inner join, left outer join, right outer join, full outer join, natural join, semi-join). The ability to JOIN tables is NOT what makes a database a Relational Database. In the almost 50 years since Codd wrote his seminal paper, hundreds of books, most accurate, have been written about this topic -- clearly, none of which you have read or understood. Many books are simply wrong since too many in the field simply want to make a buck and since Relational Databases became the marketing word of choice, every database in existence was marketed as Relational regardless of whether it was or not. This is too much the American Way -- fake it.
To be a relational database, the things generally called Tables must be Relations. Relations are a general mathematical concept. For each table is a set of rows, and the columns are set of functions of the columns which are the KEY to each function (each column) of the table. In no way does FileMaker implement the Relations and in fact, my experience with FileMaker is that it is impossible to implement Relations in FileMaker when implementing any application.
You seem confused about that and I think you're mixing up things with entity-relationship model. There are basically three data models: network model, object model and relational model. The relational model is the most natural one humanity uses since the invention of writing: some information in some row in a register matches same information in another row in another register. The relational data model is the one where the relation is carried by the existence of a data common to two rows in each table, provided that that data is unique to each row in at least one table. The two rows are said "related" because some data is common to both. When you refer to the related row not by the row number of the related one but by the existence of some real-life information common to both then you have a relational database. Entity-relationship data model is a specific implementation of relational model, not every relational database needs to be implemented under entity-relationship scheme.
In Filemaker Pro you can implement every relationship of the relational model: one-to-one, one-to-many, many-to-one, many-to-many (that by means of an intermediate table). FMP cares about the relationship for you, if that column is not unique, you cannot build a relationship starting with that. If your relationship won't work, FMP notifies you as well. FMP follows and supervises every aspect of the database scheme on behalf of the user.
We've been using it at our company for over 15 years. In that time we have slowly built it up to manage just about everything. From project management, estimating, accounting all the way down to sales on our iPads. It truly is an amazing piece of software that does not require much knowledge to get you started.
In saying that. Unless you want to make a database for your recipes, there is no way i would recommend this product for a new company at this time. I have lost complete faith and trust in Apple. On a whim, they have completely disrupted entire industries reliant on their products. People who relied on Aperture such as ourselves were left scrambling. Its just a matter of time before all other pro software such as FCPX, Logic,Filemaker, etc... follow the same fate. With Tim, it doesn't matter if a product is making money or not. If that profit number is not in the billions or it no longer fits his agenda, he has no problems crushing that department.
In corporate and professional industries, many of us rely on desktops, such as the MacPro, iMacs, minis. Apple just can't be bothered with these anymore as they are phone company now. Its one thing to update these products once every 3 or 4 years for consumers but for companies that rely on these products as tools, its just not acceptable. We've been an all Mac company for 30 years but we are now researching into PC's so we aren't left so vulnerable and reliant on unpredictable Apple.
Even though Filemaker is profitable, its a drop in the bucket for Apple. If any other software company were no longer interested in a profitable product, they would just sell it off to another software company. That's not Apple style. They don't sell IP, they kill it. For something as important as a database, that like I said, took us 15 years to build, you would be crazy to select Filemaker to build your companies database and have Apple controlling its fate. If they kill this software, we are SOL so there is no way I would choose Filemaker today if we were starting over again.
The only way this would ever change is if Apple's new CEO announced that past management dropped the ball. We are committed to the pro market. We will be updating every machine and end every software product on a 12 to 24 month timeframe.
What is important from the end user's point of view, FMP does the job. Building master-detail views with related tables is extremely easy. Invoice and invoice items, customers and their purchases... you name it. One cannot manage master-detail relationship with SQL so easily. You must create a cursor, fill that cursor with records from the related tables, then program the user interface to show the master record, then detail records from the cursor... In Filemaker Pro you just create a portal to the related table in the master record's layout and that's it...
The main difference of Filemaker Pro is that the relationships (call them joins if you wish) are fixed, they are built once and stored. SQL is extremely dynamic in building joins with the WHERE clause, you can relate any table to any table as many as you want at any time in SQL queries and get related records. It is an extremely dynamic, flexible and powerful scheme. You cannot do that in FMP dynamically, you must have thought of the relationships at the very beginning when building your solution and you cannot change those later, that requires rebuilding a database (of course you can change dynamically but this is a usage pattern, not the SQL way, so I skip that).
The point is, SQL queries in real-life applications are fixed too... Fixed and embedded into the application... So the dynamism and flexibility of SQL have no use in real-life applications. And these applications cannot get a single bit of data without issuing that embedded, frozen SELECT query again and again and again at every click…. So, why do we need to issue the same query infinite times and pass through the SQL interpreter infinite times?
This is what Filemaker Pro resolves. Filemaker Pro follows all the relationships for you, retrieves the data for you, lays it out into a layout and displays it ready for editing without awaiting a single line of query from you. In other systems, you must write programs for every minute step of data retrieval and editing processes and that, always issuing the same frozen queries again and again. In Filemaker Pro, you can build a whole business solution without writing a single line of code or script. Although novices don’t pay much attention to building a truly relational database and love to resolve everything with scripts, this is not the correct way. The ideal is to write as few scripts as possible and resolve everything within the data itself, by carefully planned table, column and relationship structures. With Filemaker Pro, you get the full power of the relational data model in your hands, and that’s it…
LARRYJW said this: "In FileMaker it's impossible to actually build an application in which the tables are true relations (which is what it means to be a relational database: table == relation)." That is pure nonsense, and he clearly has no experience with FileMaker; I have solutions with over 100 related tables in them; one can either put all the tables into a single database file, or have them spread among multiple files. In either case, the tables can be as relational as one might wish. The tables don't have "common fields;" the design schema allows the user to relate tables just as one would with SQL. LARRYJW needs to look at it before he makes incorrect assertions.
In fact, FileMaker also has the ability to use SQL queries for finding and using data. For the record, FileMaker became fully relational back in the early 90s.
Thank you longterm for proving my point. Relational databases are NOT relational because you can "relate" tables. In the language that is just a JOIN (inner join, left outer join, right outer join, full outer join, natural join, semi-join). The ability to JOIN tables is NOT what makes a database a Relational Database. In the almost 50 years since Codd wrote his seminal paper, hundreds of books, most accurate, have been written about this topic -- clearly, none of which you have read or understood. Many books are simply wrong since too many in the field simply want to make a buck and since Relational Databases became the marketing word of choice, every database in existence was marketed as Relational regardless of whether it was or not. This is too much the American Way -- fake it.
To be a relational database, the things generally called Tables must be Relations. Relations are a general mathematical concept. For each table is a set of rows, and the columns are set of functions of the columns which are the KEY to each function (each column) of the table. In no way does FileMaker implement the Relations and in fact, my experience with FileMaker is that it is impossible to implement Relations in FileMaker when implementing any application.
Most tables in Filemaker must contain fields which not functions of the supposed key of that table. Summary fields are typical examples. Global fields are another. They're values are not a function of the key of the row in which they exist. This is big deal and not some exercise in academic trivia.
Further even Oracle XE is more than a capable database server out of the box, and you don't have to spend a bundle buying a Filemaker Server -- overpriced and underperformance at any price.
Critically, Filemaker does not see the "database" as independent of the reports. If the table takes part in multiple reports, then it is typical that the table has multiple fields which are created for the multiple reports it belongs to.
As I said, the best freely accessible database is Oracle XE. It definitely has limitations over its enterprise version -- only uses one cpu, limited to 11GB of data, and true of all Oracle databases, to my chagrin, Oracle does not support large text fields or containers as relational database fields (in a formal transparent way) unlike its trivially easy-to-use versions in FileMaker, Access, MySQL (though Apex now handles these kinds of fields easily). But, like its enterprise versions, Oracle XE databases also support the very complete procedural programming language PL/SQL which at all levels blows every other database application system out of the water, especially Filemaker and even Access with in Basic language. Oracle also supports the Java language within the database (which it did long before Oracle bought Sun).
You're working far too hard to prove that FileMaker doesn't support relations. Unfortunately, for 99% of database users, the ability to relate one table to another is all they need to accommodate accomplish 100% of what they need. I've written a couple of medium-sized database apps in FileMaker and managed to relate one table to another without referring to Codd's paper or your definition.
Great database. What is missing, and since it's owned by Apple, is the direct hosting in the iCloud as I have it for Pages, Numbers etc. Not sure what they are waiting for.....but I wouldn't be suprised if the next version offers that.
FileMaker is using it's own network protocol (just like WebDav or SMB). This enables 256Bit encryption, simultaneous multi-user access and many other native functions for FileMaker clients connecting to a FileMaker Server instance. Simply placing a file in an accessible directly does not do the trick.
The "cloud" that the article briefly talks about is an instance of FileMaker Server that is customised for AWS and setup (mostly) automatically. FileMaker has chosen to work with Amazon instead of Apple on this. I'm guessing that Apple is too "focused" on their own strategy than to bend backwards to integrate solutions such as this. Amazon is probably much more flexible an environment to begin with.
It boggles my mind that this app still exists. As a former user, it's a bloated mess and I can't believe Apple still supports it. Wait, yes I can. MacBook Pro.
I've been a FileMaker Developer since around 1992, was a member of the FileMaker Business Alliance for 10 years, and Certified in versions 7 thru 13. The FileMaker product is really nice. It's not perfect, but that's very hard to achieve. FileMaker's BIGGEST problem is the the folks running the company which if fixed, FileMaker could be freaking amazing. Below I discuss all the problems I've had with FileMaker Inc. Since then they seem to be changing their ways a little at a time. FileMaker has made Feature Requests open so folks can vote on requests and they just made their road map public. Maybe FileMaker is changing, but the pricing is still NUTS and from folks I've heard from they still treat their developers like crap. Being a 'partner' has always been a one way street. https://community.filemaker.com/community/product-roadmap
Don't get me wrong, I WANT FileMaker to make a ton cash so it can be around a very long time. Making a profit is good, but not at the expense of the product. I mention this in the letter, but FileMaker 12 Server Advanced was $3k ( as a perpetual license ) which allowed hundreds of FileMaker Pro Users connect AS WELL AS 50 Web Connections. Try going to the Buy Page and see what the cost is for 60 connections ( assuming 50 web and 10 for your company ). Be sure to look at the ANNUAL vs PERPETUAL pricing. https://store.filemaker.com
"LongTerm" was right on regarding just about all of his posts above. I personally know him. He's a great person and great developer. The only point I question is "FileMaker Inc. has made a profit for EVERY year of its existence". While that might be 'true', I've heard that it's BARELY true if it is true. One person stated that it wasn't mentioned at the recent DevCon which is odd since that statement is a big deal to management. I've heard that the reason FileMaker laid off a bunch of people was to help make it true. Also, FileMaker has been offering a huge amount off if you pay for a two year contact.
FileMaker would be smart to change how they work with those in the FileMaker Business Alliance. Members can sell FileMaker to clients for a nice profit. However, FileMaker REQUIRES that the client contact be given to them. Then FileMaker starts marketing to the members clients. FileMaker has emailed my clients about events that my completion is doing. FileMaker makes also emails my clients about upgrading rather than going thru their 'trusted partner'. It's insane. I'd be ok with handing over my client info if they would actually treat me as a 'partner'. The thing is that they'd have to work with their FBA members rather than taking advantage of them. The easiest way to do this would be to set the FBA member of record on the client record. Then pay the FBA member for any sales generated by the client. That'd be reoccurring income for everyone instead of end running your "partner".
FileMaker is also losing developers over all these issues. Tim Dietrich was the first to go public about leaving FileMaker development. You can read his post at the link below. Tim was very courageous leaving FileMaker and posting what he did. He and I discussed all these issues over and over. I was too scared to speak out over worry of retribution which turned out to be valid. I've heard from other FileMaker developers that have been threatened by FileMaker too. Now that time has passed, I've learned they are just bullies with nothing to be afraid of and do not care about their developers or customers. All they want is to siphon cash from our wallets. http://timdietrich.me/blog/goodbye-filemaker/ ;
FileMaker could fix all these issues, but it seems they don't care. I brought up these issues, but they gave me the boot from the FileMaker Business Alliance rather than actually listening. We're now seeing some action, but I think that is because they are seeing their what they are doing isn't working.
FileMaker: If you're really serious about fixing all this, please speak up and have a "we're sorry" event AND listen to your developers.
I forgot to mention that while Tim and I have both left FileMaker developer due to all the issues I mentioned, we have both transitioned to using https://xojo.com which is truly spectacular. It's not the same as FileMaker and isn't right for everyone, but if you're a true developer, you'll love it.
Comments
Filemaker is very powerful. I sometimes use scripting and calculations to do text manipulation that I am not skillful enough to do with Perl or something else.
I've used Filemaker since 2.1 in the early 90's taking advantage of the fact it could handle
Cyrillic and Japanese. I think the relational stuff came along more mid-late 90's but even with the earlier versions you could fake some things with look ups.
My main complaint is that for the non-developer, the "layout" user interface has gotten pretty difficult. It used to be much easier to use.
To be a relational database, the things generally called Tables must be Relations. Relations are a general mathematical concept. For each table is a set of rows, and the columns are set of functions of the columns which are the KEY to each function (each column) of the table. In no way does FileMaker implement the Relations and in fact, my experience with FileMaker is that it is impossible to implement Relations in FileMaker when implementing any application.
Most tables in Filemaker must contain fields which not functions of the supposed key of that table. Summary fields are typical examples. Global fields are another. They're values are not a function of the key of the row in which they exist. This is big deal and not some exercise in academic trivia.
Further even Oracle XE is more than a capable database server out of the box, and you don't have to spend a bundle buying a Filemaker Server -- overpriced and underperformance at any price.
In Filemaker Pro you can implement every relationship of the relational model: one-to-one, one-to-many, many-to-one, many-to-many (that by means of an intermediate table). FMP cares about the relationship for you, if that column is not unique, you cannot build a relationship starting with that. If your relationship won't work, FMP notifies you as well. FMP follows and supervises every aspect of the database scheme on behalf of the user.
We've been using it at our company for over 15 years. In that time we have slowly built it up to manage just about everything. From project management, estimating, accounting all the way down to sales on our iPads. It truly is an amazing piece of software that does not require much knowledge to get you started.
In saying that. Unless you want to make a database for your recipes, there is no way i would recommend this product for a new company at this time. I have lost complete faith and trust in Apple. On a whim, they have completely disrupted entire industries reliant on their products. People who relied on Aperture such as ourselves were left scrambling. Its just a matter of time before all other pro software such as FCPX, Logic,Filemaker, etc... follow the same fate. With Tim, it doesn't matter if a product is making money or not. If that profit number is not in the billions or it no longer fits his agenda, he has no problems crushing that department.
In corporate and professional industries, many of us rely on desktops, such as the MacPro, iMacs, minis. Apple just can't be bothered with these anymore as they are phone company now. Its one thing to update these products once every 3 or 4 years for consumers but for companies that rely on these products as tools, its just not acceptable. We've been an all Mac company for 30 years but we are now researching into PC's so we aren't left so vulnerable and reliant on unpredictable Apple.
Even though Filemaker is profitable, its a drop in the bucket for Apple. If any other software company were no longer interested in a profitable product, they would just sell it off to another software company. That's not Apple style. They don't sell IP, they kill it. For something as important as a database, that like I said, took us 15 years to build, you would be crazy to select Filemaker to build your companies database and have Apple controlling its fate. If they kill this software, we are SOL so there is no way I would choose Filemaker today if we were starting over again.
The only way this would ever change is if Apple's new CEO announced that past management dropped the ball. We are committed to the pro market. We will be updating every machine and end every software product on a 12 to 24 month timeframe.
What is important from the end user's point of view, FMP does the job. Building master-detail views with related tables is extremely easy. Invoice and invoice items, customers and their purchases... you name it. One cannot manage master-detail relationship with SQL so easily. You must create a cursor, fill that cursor with records from the related tables, then program the user interface to show the master record, then detail records from the cursor... In Filemaker Pro you just create a portal to the related table in the master record's layout and that's it...
The main difference of Filemaker Pro is that the relationships (call them joins if you wish) are fixed, they are built once and stored. SQL is extremely dynamic in building joins with the WHERE clause, you can relate any table to any table as many as you want at any time in SQL queries and get related records. It is an extremely dynamic, flexible and powerful scheme. You cannot do that in FMP dynamically, you must have thought of the relationships at the very beginning when building your solution and you cannot change those later, that requires rebuilding a database (of course you can change dynamically but this is a usage pattern, not the SQL way, so I skip that).
The point is, SQL queries in real-life applications are fixed too... Fixed and embedded into the application... So the dynamism and flexibility of SQL have no use in real-life applications. And these applications cannot get a single bit of data without issuing that embedded, frozen SELECT query again and again and again at every click…. So, why do we need to issue the same query infinite times and pass through the SQL interpreter infinite times?
This is what Filemaker Pro resolves. Filemaker Pro follows all the relationships for you, retrieves the data for you, lays it out into a layout and displays it ready for editing without awaiting a single line of query from you. In other systems, you must write programs for every minute step of data retrieval and editing processes and that, always issuing the same frozen queries again and again. In Filemaker Pro, you can build a whole business solution without writing a single line of code or script. Although novices don’t pay much attention to building a truly relational database and love to resolve everything with scripts, this is not the correct way. The ideal is to write as few scripts as possible and resolve everything within the data itself, by carefully planned table, column and relationship structures. With Filemaker Pro, you get the full power of the relational data model in your hands, and that’s it…
The "cloud" that the article briefly talks about is an instance of FileMaker Server that is customised for AWS and setup (mostly) automatically. FileMaker has chosen to work with Amazon instead of Apple on this. I'm guessing that Apple is too "focused" on their own strategy than to bend backwards to integrate solutions such as this. Amazon is probably much more flexible an environment to begin with.
I wrote a letter to Tim Cook in December 2015 to discuss how management is holding the product back from what it could be as a last hope. You can read that email where I go into excruciating detail: http://CampSoftware.com/download/FileMakerIncisRuiningtheFileMakerPlatform.pdf
Don't get me wrong, I WANT FileMaker to make a ton cash so it can be around a very long time. Making a profit is good, but not at the expense of the product. I mention this in the letter, but FileMaker 12 Server Advanced was $3k ( as a perpetual license ) which allowed hundreds of FileMaker Pro Users connect AS WELL AS 50 Web Connections. Try going to the Buy Page and see what the cost is for 60 connections ( assuming 50 web and 10 for your company ). Be sure to look at the ANNUAL vs PERPETUAL pricing. https://store.filemaker.com
"LongTerm" was right on regarding just about all of his posts above. I personally know him. He's a great person and great developer. The only point I question is "FileMaker Inc. has made a profit for EVERY year of its existence". While that might be 'true', I've heard that it's BARELY true if it is true. One person stated that it wasn't mentioned at the recent DevCon which is odd since that statement is a big deal to management. I've heard that the reason FileMaker laid off a bunch of people was to help make it true. Also, FileMaker has been offering a huge amount off if you pay for a two year contact.
FileMaker would be smart to change how they work with those in the FileMaker Business Alliance. Members can sell FileMaker to clients for a nice profit. However, FileMaker REQUIRES that the client contact be given to them. Then FileMaker starts marketing to the members clients. FileMaker has emailed my clients about events that my completion is doing. FileMaker makes also emails my clients about upgrading rather than going thru their 'trusted partner'. It's insane. I'd be ok with handing over my client info if they would actually treat me as a 'partner'. The thing is that they'd have to work with their FBA members rather than taking advantage of them. The easiest way to do this would be to set the FBA member of record on the client record. Then pay the FBA member for any sales generated by the client. That'd be reoccurring income for everyone instead of end running your "partner".
FileMaker is also losing developers over all these issues. Tim Dietrich was the first to go public about leaving FileMaker development. You can read his post at the link below. Tim was very courageous leaving FileMaker and posting what he did. He and I discussed all these issues over and over. I was too scared to speak out over worry of retribution which turned out to be valid. I've heard from other FileMaker developers that have been threatened by FileMaker too. Now that time has passed, I've learned they are just bullies with nothing to be afraid of and do not care about their developers or customers. All they want is to siphon cash from our wallets.
http://timdietrich.me/blog/goodbye-filemaker/ ;
FileMaker could fix all these issues, but it seems they don't care. I brought up these issues, but they gave me the boot from the FileMaker Business Alliance rather than actually listening. We're now seeing some action, but I think that is because they are seeing their what they are doing isn't working.
FileMaker: If you're really serious about fixing all this, please speak up and have a "we're sorry" event AND listen to your developers.