Beats the shit out of Access. FileMaker is far more powerful and robust.
As much as I despise MS, that's nonsense. There is not a single thing FM can do that Access can't, and it is hundreds of things Access can do that FM can't. And Access did get pretty robust over the years. Until two years ago we were running an access based employee information system (a stopgap solution, it now is on MySQL) with almost 1100 clients (the master Access database sitting on a lowly Pentium III)... no problems whatsoever. Over the years Access learned almost full SQL support and even table-level stored procedures and triggers... while FM still can't even properly connect a form view to a query or parameterized view (without extremely involved workarounds that are documented nowhere). Even comparing Access' documentation and support to FM, FM gets a severely rotten banana. Sorry, but they are not even on the same page.
Laying off 20 people is not a good sign for an Apple family company. This is serious! We've all been reading how Android has been eating Apple's lunch, and now this! Watch for the GOP to bring it up in a news conference, " Even America's strongest company is turning workers out of their cubicles. Some of those who have been at their jobs for over a decade were handed a large box and sat out on the street and told to 'go fish'."
Sure I read somewhere that Google had reduced its number of employees by thousands - not a measly 20.
But compared to even Access or Paradox, a simple task like getting data out of a RDBMS, running a subquery and a custom sortation on it and outputting the result in something like a drill-down or complex grouped master-detail report, a task we face almost daily, FM is dead last. The layout manager for forms is a nightmare, the reporting module is the poorest in existence and basic SQL support is close to zero. The Claris Works approach and GUI was good for the most basic tasks two to three decades ago. A major overhaul never happened.
I think you're missing something here. For many thousands of users, both personal and business, Filemaker IS THE RDBMS, and all the issues you mention about SQL support are completely irrelevant. There is a huge range of applications which require nothing outside of the Filemaker environment, and there is no need for any bridges to SQL/PHP/XML/whatever. If it weren't so expensive it would have captured a much greater market share for small to mid size business use.
As much as I despise MS, that's nonsense. There is not a single thing FM can do that Access can't, and it is hundreds of things Access can do that FM can't. And Access did get pretty robust over the years. Until two years ago we were running an access based employee information system (a stopgap solution, it now is on MySQL) with almost 1100 clients (the master Access database sitting on a lowly Pentium III)... no problems whatsoever. Over the years Access learned almost full SQL support and even table-level stored procedures and triggers... while FM still can't even properly connect a form view to a query or parameterized view (without extremely involved workarounds that are documented nowhere). Even comparing Access' documentation and support to FM, FM gets a severely rotten banana. Sorry, but they are not even on the same page.
Which version of FileMaker are you talking about?
FileMaker 12 supports SQL commands internally and externally in addition to XML queries.
We've had few issues connecting FM to our MSSQL system.
If you're still talking about ClarisWorks you seem to be like so many people who have not used FileMaker in over a decade.
Executes an SQL query statement for the specified table occurrence within a FileMaker Pro database. This command can be sent to FM via a XML query without having to exporting data from FM to search data.
I think you're missing something here. For many thousands of users, both personal and business, Filemaker IS THE RDBMS, and all the issues you mention about SQL support are completely irrelevant. There is a huge range of applications which require nothing outside of the Filemaker environment, and there is no need for any bridges to SQL/PHP/XML/whatever. If it weren't so expensive it would have captured a much greater market share for small to mid size business use.
Oh yeah? Outside of the Mac community, how many FM users are there? I have, over the last 25 years, not seen a single Windows-only environment where people even know FM. And they do not need to, because pretty much every alternative is better and normally cheaper.
And no solution is an island. "There is no need for any bridges to SQL/PHP/XML/whatever" is simply out of sync with reality. Even our most simple in-house apps do require the integration of other data sources, no matter if web data (like current exchange rates), CRM/ERM data lookups, or data belonging to other apps or third-party/infrastructure data. The alternative would be to duplicate data and create the same mess we had in the nineties (when the downsizing idiots talked us into having every piece of information at least twice, just to avoid integration and format issues). In my company at that time the final clean-up in the early 2000s costed almost 25 million USD. Doing it properly in the beginning would have costed less than 1/10th of that.
If a photographer or musician, who is on a Mac anyhow, maintains a FM database for his own organisational needs, fine. For everything connected and integrated, forget it. It is just a more complicated version of the simple DB-like framework Claris offered in the dark ages of computing... flat tables, a few GUI controls, some pagination and search and a reporting engine that has not more to offer than mail merge in Word. As I said above, we only keep it around as a simple and cost-effective mean to get some (mainly read-only) data to iDevices. But compared to our self-designed in-house apps, even the least computer-knowledgeable staff members do realise that it is crap.
I support a number of charities and small enterprises and a fair number of them use FileMaker. Most of them are still on very old versions of FileMaker they bought when they initially started up, that means from version 10 to version 3, with most on Version 6. I enquire why they don't upgrade and find most haven't got the funding to upgrade, leaving new workers with no access to any database as they can't buy old versions. This means there are many possible users that would upgrade if the price was much lower, with most having under 10 users, they don't need FileMaker Server.
So put it on App Store for $50 with Bento for $4.99 and get thing moving.
Oh yeah? Outside of the Mac community, how many FM users are there? I have, over the last 25 years, not seen a single Windows-only environment where people even know FM. And they do not need to, because pretty much every alternative is better and normally cheaper.
And no solution is an island. "There is no need for any bridges to SQL/PHP/XML/whatever" is simply out of sync with reality. Even our most simple in-house apps do require the integration of other data sources, no matter if web data (like current exchange rates), CRM/ERM data lookups, or data belonging to other apps or third-party/infrastructure data. The alternative would be to duplicate data and create the same mess we had in the nineties (when the downsizing idiots talked us into having every piece of information at least twice, just to avoid integration and format issues). In my company at that time the final clean-up in the early 2000s costed almost 25 million USD. Doing it properly in the beginning would have costed less than 1/10th of that.
If a photographer or musician, who is on a Mac anyhow, maintains a FM database for his own organisational needs, fine. For everything connected and integrated, forget it. It is just a more complicated version of the simple DB-like framework Claris offered in the dark ages of computing... flat tables, a few GUI controls, some pagination and search and a reporting engine that has not more to offer than mail merge in Word. As I said above, we only keep it around as a simple and cost-effective mean to get some (mainly read-only) data to iDevices. But compared to our self-designed in-house apps, even the least computer-knowledgeable staff members do realise that it is crap.
What the last version you used? Anyone still talking about ClarisWorks probably hasn't used it in a decade thus making your comments invalid.
FileMaker 12 supports native SQL queries internally or via XML requests externally.
I support a number of charities and small enterprises and a fair number of them use FileMaker. Most of them are still on very old versions of FileMaker they bought when they initially started up, that means from version 10 to version 3, with most on Version 6. I enquire why they don't upgrade and find most haven't got the funding to upgrade, leaving new workers with no access to any database as they can't buy old versions. This means there are many possible users that would upgrade if the price was much lower, with most having under 10 users, they don't need FileMaker Server.
So put it on App Store for $50 with Bento for $4.99 and get thing moving.
Have you tried AVAL (Annual Volume Licensing)? Plus if you get AVAL or not FileMaker Go is free.
I don't think a lot of people understand all their FM options to include FM Server and Server Advanced to include unlimited FM Go options.
FileMaker 12 supports SQL commands internally and externally in addition to XML queries.
We've had few issues connecting FM to our MSSQL system.
If you're still talking about ClarisWorks you seem to be like so many people who have not used FileMaker in over a decade.
Executes an SQL query statement for the specified table occurrence within a FileMaker Pro database. This command can be sent to FM via a XML query without having to exporting data from FM to search data.
Thanks, we do use FM 12 (Advanced Pro for the developers and the Advanced Server plus FM Go on iPad and iPhone), and we do know the ExecuteSQL function quite well.
Let me make a (simplified) real life example: We have a project database (project steps, responsibilities, tasks and assignments, status reports) in MySQL, customer detail data (like e.g. staff rates and customer rebates) in SAP, exchange rates (all our rates are based on the Euro) come from our house bank. The FM database contains documents related to the project, hours booked by staff members, risk, change and issue management data and a query register for each project.
Now, as we work with tons of free-lancers, we need to limit the visibility of data to the extent possible. So, if a staff member calls up the project app on an iDevice, he should only see projects he is assigned to (either as a project manager or a staff member), he should only be able to record hours against assignments/tasks within these projects, he should only see e.g. converted rates and rebates for his projects, he should only see risks and issues up to his clearance level (e.g. certain items might be PM and management only). For security (and bandwidth / performance) purposes, filtering should happen on the server, as data that is not meant to be seen, should not be transmitted in the first place.
Now, doing this with queries and/or views is trivial, but ExecuteSQL can only return character-separated values, not true datasets (which e.g. fails immediately with memo fields, as they will often contain the column or row separators specified). We had our best people, FileMaker people (from their German support) and a FileMaker consultant working on this for months. There are means to hide / exclude data within the app, but there is no foolproof way to transmit anything else than full views/tables, unless you define individual views for each staff member (which is a nightmare). Now, this is grossly simplified, as e.g. the same logic applies to each look-up in entry forms (the should only contain lookup values relevant to this user), the read-only or write status for some existing values depends on the user status (PM or staff member), all exchange rates pulled need to be written to an additional logging table with a date/time stamp, changes to existing data need to be logged as well (with old/new values, timestamp and user id) etc. Doing that in Access or on a PHP page is a snap, doing it in FM turned out to be as cumbersome as writing it in Xcode from scratch in some cases.
In implementing that we hit tons on limitations and even more cases where the user documentation was simply non-existent. Our programmers solved the majority of problems by going through third-party sample code from other apps (on third party sites) - an extremely time consuming process. We had several cases where FM support clearly told us that something is not possible at all, and it turned out to be dead wrong.
Thanks, we do use FM 12 (Advanced Pro for the developers and the Advanced Server plus FM Go on iPad and iPhone), and we do know the ExecuteSQL function quite well.
Let me make a (simplified) real life example: We have a project database (project steps, responsibilities, tasks and assignments, status reports) in MySQL, customer detail data (like e.g. staff rates and customer rebates) in SAP, exchange rates (all our rates are based on the Euro) come from our house bank. The FM database contains documents related to the project, hours booked by staff members, risk, change and issue management data and a query register for each project.
Now, as we work with tons of free-lancers, we need to limit the visibility of data to the extent possible. So, if a staff member calls up the project app on an iDevice, he should only see projects he is assigned to (either as a project manager or a staff member), he should only be able to record hours against assignments/tasks within these projects, he should only see e.g. converted rates and rebates for his projects, he should only see risks and issues up to his clearance level (e.g. certain items might be PM and management only). For security (and bandwidth / performance) purposes, filtering should happen on the server, as data that is not meant to be seen, should not be transmitted in the first place.
Now, doing this with queries and/or views is trivial, but ExecuteSQL can only return character-separated values, not true datasets (which e.g. fails immediately with memo fields, as they will often contain the column or row separators specified). We had our best people, FileMaker people (from their German support) and a FileMaker consultant working on this for months. There are means to hide / exclude data within the app, but there is no foolproof way to transmit anything else than full views/tables, unless you define individual views for each staff member (which is a nightmare). Now, this is grossly simplified, as e.g. the same logic applies to each look-up in entry forms (the should only contain lookup values relevant to this user), the read-only or write status for some existing values depends on the user status (PM or staff member), all exchange rates pulled need to be written to an additional logging table with a date/time stamp, changes to existing data need to be logged as well (with old/new values, timestamp and user id) etc. Doing that in Access or on a PHP page is a snap, doing it in FM turned out to be as cumbersome as writing it in Xcode from scratch in some cases.
In implementing that we hit tons on limitations and even more cases where the user documentation was simply non-existent. Our programmers solved the majority of problems by going through third-party sample code from other apps (on third party sites) - an extremely time consuming process. We had several cases where FM support clearly told us that something is not possible at all, and it turned out to be dead wrong.
I built a real-time operations and inventory planning, tracking and execution system for a multi-million dollar company using FileMaker (cross-platform) so I (also) speak from experience. What I do know is that to use FileMaker effectively you need to understand it's best uses.
If you're trying to use it in enterprise as a static solution for a company over 1000 people as a long-term (permanent) solution then you probably have the wrong tool. If you're already using SAP, as I said, it's probably not the best solution for you unless you're using it as a local/temporary solution or as a prototyping tool.
FileMaker is great for small and medium sized businesses (business unit of a bigger company) not just "a photographer or musician". Sounds like you have a bias against a OSX not just FileMaker. Plenty of serious work gets done on a Mac, just ask NASA.
You know, Visual Studio, Access, SQL, etc, are all great and everything but from what I've seen a lot of corporate IT departments don't have any design skills and end up developing some of the worse designed shit I've ever seen, unusable crap. Sure it's technically wonderful but crap for the user all the same. I'm not saying your work is crap but I know what I've seen and it still took months or years for them to do what I could do in weeks.
In the end it all depends on what you need, when you need it and if it works for you. In our case SAP was a non-starter even for our multi-million dollar contracts due to time constraints and ever changing missions.
This is a bit worrying, not because Bento being killed off is a big loss (it's not!) but because it's essentially the same management behind FileMaker too and that software is too important to meet the same fate.
FileMaker is good but it has more or less stagnated in the past 5 or 6 versions. If their idea of important development is adding new templates then that's a pretty poor indictment of their management and development teams.
FileMaker needs a big update to improve usability, applicability and integrity of data. When I use it I'm constantly worried that I'll make inadvertent edits and not realise due to the lack of any form of change tracking and undo. From what I've read the Go application needs work too.
What we need is a real FCP/Logic Pro X level of rethinking and not just more stagnation-ware updates that do little to enhance the product or address weaknesses.
Apple should really step in and absorb the company and take it over because otherwise I can see FileMaker meeting the same fate.
I should also add that my use of FileMaker was for managing/storing and transforming large scientific databases so change tracking is really critical for the integrity of data.
Of course there are lots of other tools on the PC side and even basic command-line editors to perform some of the work, but I still really want and need a good, native Mac database application that performs well with millions of records for whenever I work in the Mac environment.
We use Bento daily in my laboratory to track inventory. Its simple and cheap and does what we need it to do. Looks like we'll never be updating that computer until it dies.
Reminds me of when I lost the database along with Appleworks. Ugh, Apple -nee Claris - giveth and taketh away.
Executes an SQL query statement for the specified table occurrence within a FileMaker Pro database. This command can be sent to FM via a XML query without having to exporting data from FM to search data.
Now, doing this with queries and/or views is trivial, but ExecuteSQL can only return character-separated values, not true datasets (which e.g. fails immediately with memo fields, as they will often contain the column or row separators specified).
Data Type returned is text not array. If you cannot selectively address the nodes and all you get back is a comma separated list of all fields in a row it doesn't offer very much flexibility.
ExecuteSQL cannot be used with SQL statements that modify data or the database schema
It does only one of the four major commands. (does SELECT, not UPDATE, INSERT, DELETE)
If a database has such poor SQL compliancy why would anyone even mention it?
Is there anything equivalent to Filemaker Go on Android and Win RT?
From what I understand it has been quite popular for developing custom business tools to run on iPads and iPhones and even help adoption of iOS devices in businesses. Despite some of the comments here, I think that Filemaker is not only doing just fine, but its business is booming right now. I would not have any problem finding a job as a Filemaker programmer.
Not everyone needs SQL support and run into those issues. Sure it has its quirks, but is very similar to Hypercard in terms of being easy to deploy relatively powerful solution in a short amount of time.
And BTW the name of the DogCow is Clarus, not Claris. She would be ashamed
I don't use Bento that much, but believe it should be shifted to iWork.
Apple's gone too long with iWork on the back shelf - now is a very good time to bring it forward on all platforms - including iCloud. Add in Bento (even if under a different name) and make it a full package.
I can understand that Apple has had a huge focus on iOS development, but the consumer apps in iLife and iWork have been a driving force in Apple selling more Macs over the past decade. No matter how much I love my iPhone it's still the MBP that get the most of my time.
I used FileMaker way back in the early 90s. Since then, I've gone back to it from time to time, but haven't touched it in a few years.
It's a shame because there is a need for a simple database app on both OS X and iOS.
What I don't understand is why can't Apple bring FileMaker back in house and reboot it as follows:
Make it MySQL based. Allow it to either run locally for personal database usage, or connected to a hosted MySQL database.
Allow simple tools for creating buttons, scripts, layouts etc...
Sell inexpensive client versions for iOS, OS X and Windows.
Sell moderately priced producer versions for OS X.
Sell admin/server versions for OS X.
Create an App Store for FileMaker that allows people to sell (or distribute for free) templates or full fledged FileMaker based apps. The producer version could allow the production of native apps for iOS, OS X and Windows that are essentially the client, but tied to specific templates and in some cases specific databases.
The thing, is something like this could be huge in many ways... for example, I'm running all kinds of PHP scripts and MySQL queries all the time to deal with WordPress, it would be awesome to be able to deliver those scripts as apps for iOS, OS X and Windows.
I may be way off base, having not used FileMaker in such a long time, but there does seems to be a need for something to draw people back into it.
What I don't understand is why can't Apple bring FileMaker back in house and reboot it as follows:
Make it MySQL based. Allow it to either run locally for personal database usage, or connected to a hosted MySQL database.
They can't base their software off of MySql because MySql is owned by Oracle. It is free to use for end users but you cant take MySql code and resell it as your own application.
SQLite would be excellent for a lightweight dB and is already on all Macs, iDevices and built into Safari, and the source code is in the public domain.
I have used Bento since the beta and have been a FileMaker developer since version 2 of that program.
I liked the easy methods of Bento and it was far simpler for my wife and kids to use Bento and sync to their iPhones/iPads.
If you are looking for the same type of thing as a replacement you should definitely check out TapForms on the Mac and for iDevices. It is very nice. The costs are pretty good too in comparison to even Bento.
I am switching to that since they added iCould syncing and the Mac OS version.
Still use FileMaker for my heavier lifting database stuff.
PS: what the hell is a "spreadsheet"? I avoid them like the plague. I only use them as an absolute last resort for a very specific task.
Comments
As much as I despise MS, that's nonsense. There is not a single thing FM can do that Access can't, and it is hundreds of things Access can do that FM can't. And Access did get pretty robust over the years. Until two years ago we were running an access based employee information system (a stopgap solution, it now is on MySQL) with almost 1100 clients (the master Access database sitting on a lowly Pentium III)... no problems whatsoever. Over the years Access learned almost full SQL support and even table-level stored procedures and triggers... while FM still can't even properly connect a form view to a query or parameterized view (without extremely involved workarounds that are documented nowhere). Even comparing Access' documentation and support to FM, FM gets a severely rotten banana. Sorry, but they are not even on the same page.
Sure I read somewhere that Google had reduced its number of employees by thousands - not a measly 20.
Quote:
Originally Posted by dreyfus2
But compared to even Access or Paradox, a simple task like getting data out of a RDBMS, running a subquery and a custom sortation on it and outputting the result in something like a drill-down or complex grouped master-detail report, a task we face almost daily, FM is dead last. The layout manager for forms is a nightmare, the reporting module is the poorest in existence and basic SQL support is close to zero. The Claris Works approach and GUI was good for the most basic tasks two to three decades ago. A major overhaul never happened.
I think you're missing something here. For many thousands of users, both personal and business, Filemaker IS THE RDBMS, and all the issues you mention about SQL support are completely irrelevant. There is a huge range of applications which require nothing outside of the Filemaker environment, and there is no need for any bridges to SQL/PHP/XML/whatever. If it weren't so expensive it would have captured a much greater market share for small to mid size business use.
Quote:
Originally Posted by dreyfus2
As much as I despise MS, that's nonsense. There is not a single thing FM can do that Access can't, and it is hundreds of things Access can do that FM can't. And Access did get pretty robust over the years. Until two years ago we were running an access based employee information system (a stopgap solution, it now is on MySQL) with almost 1100 clients (the master Access database sitting on a lowly Pentium III)... no problems whatsoever. Over the years Access learned almost full SQL support and even table-level stored procedures and triggers... while FM still can't even properly connect a form view to a query or parameterized view (without extremely involved workarounds that are documented nowhere). Even comparing Access' documentation and support to FM, FM gets a severely rotten banana. Sorry, but they are not even on the same page.
Which version of FileMaker are you talking about?
FileMaker 12 supports SQL commands internally and externally in addition to XML queries.
We've had few issues connecting FM to our MSSQL system.
If you're still talking about ClarisWorks you seem to be like so many people who have not used FileMaker in over a decade.
Executes an SQL query statement for the specified table occurrence within a FileMaker Pro database. This command can be sent to FM via a XML query without having to exporting data from FM to search data.
ExecuteSQL(sqlQuery; fieldSeparator; rowSeparator {;arguments...})
ExecuteSQL
http://www.filemaker.com/12help/html/func_ref3.33.6.html
Oh yeah? Outside of the Mac community, how many FM users are there? I have, over the last 25 years, not seen a single Windows-only environment where people even know FM. And they do not need to, because pretty much every alternative is better and normally cheaper.
And no solution is an island. "There is no need for any bridges to SQL/PHP/XML/whatever" is simply out of sync with reality. Even our most simple in-house apps do require the integration of other data sources, no matter if web data (like current exchange rates), CRM/ERM data lookups, or data belonging to other apps or third-party/infrastructure data. The alternative would be to duplicate data and create the same mess we had in the nineties (when the downsizing idiots talked us into having every piece of information at least twice, just to avoid integration and format issues). In my company at that time the final clean-up in the early 2000s costed almost 25 million USD. Doing it properly in the beginning would have costed less than 1/10th of that.
If a photographer or musician, who is on a Mac anyhow, maintains a FM database for his own organisational needs, fine. For everything connected and integrated, forget it. It is just a more complicated version of the simple DB-like framework Claris offered in the dark ages of computing... flat tables, a few GUI controls, some pagination and search and a reporting engine that has not more to offer than mail merge in Word. As I said above, we only keep it around as a simple and cost-effective mean to get some (mainly read-only) data to iDevices. But compared to our self-designed in-house apps, even the least computer-knowledgeable staff members do realise that it is crap.
I support a number of charities and small enterprises and a fair number of them use FileMaker. Most of them are still on very old versions of FileMaker they bought when they initially started up, that means from version 10 to version 3, with most on Version 6. I enquire why they don't upgrade and find most haven't got the funding to upgrade, leaving new workers with no access to any database as they can't buy old versions. This means there are many possible users that would upgrade if the price was much lower, with most having under 10 users, they don't need FileMaker Server.
So put it on App Store for $50 with Bento for $4.99 and get thing moving.
Quote:
Originally Posted by dreyfus2
Oh yeah? Outside of the Mac community, how many FM users are there? I have, over the last 25 years, not seen a single Windows-only environment where people even know FM. And they do not need to, because pretty much every alternative is better and normally cheaper.
And no solution is an island. "There is no need for any bridges to SQL/PHP/XML/whatever" is simply out of sync with reality. Even our most simple in-house apps do require the integration of other data sources, no matter if web data (like current exchange rates), CRM/ERM data lookups, or data belonging to other apps or third-party/infrastructure data. The alternative would be to duplicate data and create the same mess we had in the nineties (when the downsizing idiots talked us into having every piece of information at least twice, just to avoid integration and format issues). In my company at that time the final clean-up in the early 2000s costed almost 25 million USD. Doing it properly in the beginning would have costed less than 1/10th of that.
If a photographer or musician, who is on a Mac anyhow, maintains a FM database for his own organisational needs, fine. For everything connected and integrated, forget it. It is just a more complicated version of the simple DB-like framework Claris offered in the dark ages of computing... flat tables, a few GUI controls, some pagination and search and a reporting engine that has not more to offer than mail merge in Word. As I said above, we only keep it around as a simple and cost-effective mean to get some (mainly read-only) data to iDevices. But compared to our self-designed in-house apps, even the least computer-knowledgeable staff members do realise that it is crap.
What the last version you used? Anyone still talking about ClarisWorks probably hasn't used it in a decade thus making your comments invalid.
FileMaker 12 supports native SQL queries internally or via XML requests externally.
Quote:
Originally Posted by sodimm
I support a number of charities and small enterprises and a fair number of them use FileMaker. Most of them are still on very old versions of FileMaker they bought when they initially started up, that means from version 10 to version 3, with most on Version 6. I enquire why they don't upgrade and find most haven't got the funding to upgrade, leaving new workers with no access to any database as they can't buy old versions. This means there are many possible users that would upgrade if the price was much lower, with most having under 10 users, they don't need FileMaker Server.
So put it on App Store for $50 with Bento for $4.99 and get thing moving.
Have you tried AVAL (Annual Volume Licensing)? Plus if you get AVAL or not FileMaker Go is free.
I don't think a lot of people understand all their FM options to include FM Server and Server Advanced to include unlimited FM Go options.
Oh, Bento is dead. They discontinued it.
Thanks, we do use FM 12 (Advanced Pro for the developers and the Advanced Server plus FM Go on iPad and iPhone), and we do know the ExecuteSQL function quite well.
Let me make a (simplified) real life example: We have a project database (project steps, responsibilities, tasks and assignments, status reports) in MySQL, customer detail data (like e.g. staff rates and customer rebates) in SAP, exchange rates (all our rates are based on the Euro) come from our house bank. The FM database contains documents related to the project, hours booked by staff members, risk, change and issue management data and a query register for each project.
Now, as we work with tons of free-lancers, we need to limit the visibility of data to the extent possible. So, if a staff member calls up the project app on an iDevice, he should only see projects he is assigned to (either as a project manager or a staff member), he should only be able to record hours against assignments/tasks within these projects, he should only see e.g. converted rates and rebates for his projects, he should only see risks and issues up to his clearance level (e.g. certain items might be PM and management only). For security (and bandwidth / performance) purposes, filtering should happen on the server, as data that is not meant to be seen, should not be transmitted in the first place.
Now, doing this with queries and/or views is trivial, but ExecuteSQL can only return character-separated values, not true datasets (which e.g. fails immediately with memo fields, as they will often contain the column or row separators specified). We had our best people, FileMaker people (from their German support) and a FileMaker consultant working on this for months. There are means to hide / exclude data within the app, but there is no foolproof way to transmit anything else than full views/tables, unless you define individual views for each staff member (which is a nightmare). Now, this is grossly simplified, as e.g. the same logic applies to each look-up in entry forms (the should only contain lookup values relevant to this user), the read-only or write status for some existing values depends on the user status (PM or staff member), all exchange rates pulled need to be written to an additional logging table with a date/time stamp, changes to existing data need to be logged as well (with old/new values, timestamp and user id) etc. Doing that in Access or on a PHP page is a snap, doing it in FM turned out to be as cumbersome as writing it in Xcode from scratch in some cases.
In implementing that we hit tons on limitations and even more cases where the user documentation was simply non-existent. Our programmers solved the majority of problems by going through third-party sample code from other apps (on third party sites) - an extremely time consuming process. We had several cases where FM support clearly told us that something is not possible at all, and it turned out to be dead wrong.
Quote:
Originally Posted by dreyfus2
Thanks, we do use FM 12 (Advanced Pro for the developers and the Advanced Server plus FM Go on iPad and iPhone), and we do know the ExecuteSQL function quite well.
Let me make a (simplified) real life example: We have a project database (project steps, responsibilities, tasks and assignments, status reports) in MySQL, customer detail data (like e.g. staff rates and customer rebates) in SAP, exchange rates (all our rates are based on the Euro) come from our house bank. The FM database contains documents related to the project, hours booked by staff members, risk, change and issue management data and a query register for each project.
Now, as we work with tons of free-lancers, we need to limit the visibility of data to the extent possible. So, if a staff member calls up the project app on an iDevice, he should only see projects he is assigned to (either as a project manager or a staff member), he should only be able to record hours against assignments/tasks within these projects, he should only see e.g. converted rates and rebates for his projects, he should only see risks and issues up to his clearance level (e.g. certain items might be PM and management only). For security (and bandwidth / performance) purposes, filtering should happen on the server, as data that is not meant to be seen, should not be transmitted in the first place.
Now, doing this with queries and/or views is trivial, but ExecuteSQL can only return character-separated values, not true datasets (which e.g. fails immediately with memo fields, as they will often contain the column or row separators specified). We had our best people, FileMaker people (from their German support) and a FileMaker consultant working on this for months. There are means to hide / exclude data within the app, but there is no foolproof way to transmit anything else than full views/tables, unless you define individual views for each staff member (which is a nightmare). Now, this is grossly simplified, as e.g. the same logic applies to each look-up in entry forms (the should only contain lookup values relevant to this user), the read-only or write status for some existing values depends on the user status (PM or staff member), all exchange rates pulled need to be written to an additional logging table with a date/time stamp, changes to existing data need to be logged as well (with old/new values, timestamp and user id) etc. Doing that in Access or on a PHP page is a snap, doing it in FM turned out to be as cumbersome as writing it in Xcode from scratch in some cases.
In implementing that we hit tons on limitations and even more cases where the user documentation was simply non-existent. Our programmers solved the majority of problems by going through third-party sample code from other apps (on third party sites) - an extremely time consuming process. We had several cases where FM support clearly told us that something is not possible at all, and it turned out to be dead wrong.
I built a real-time operations and inventory planning, tracking and execution system for a multi-million dollar company using FileMaker (cross-platform) so I (also) speak from experience. What I do know is that to use FileMaker effectively you need to understand it's best uses.
If you're trying to use it in enterprise as a static solution for a company over 1000 people as a long-term (permanent) solution then you probably have the wrong tool. If you're already using SAP, as I said, it's probably not the best solution for you unless you're using it as a local/temporary solution or as a prototyping tool.
FileMaker is great for small and medium sized businesses (business unit of a bigger company) not just "a photographer or musician". Sounds like you have a bias against a OSX not just FileMaker. Plenty of serious work gets done on a Mac, just ask NASA.
http://www.tekserve.com/business/wp-content/uploads/2012/08/Nasa-Macs.jpeg
You know, Visual Studio, Access, SQL, etc, are all great and everything but from what I've seen a lot of corporate IT departments don't have any design skills and end up developing some of the worse designed shit I've ever seen, unusable crap. Sure it's technically wonderful but crap for the user all the same. I'm not saying your work is crap but I know what I've seen and it still took months or years for them to do what I could do in weeks.
In the end it all depends on what you need, when you need it and if it works for you. In our case SAP was a non-starter even for our multi-million dollar contracts due to time constraints and ever changing missions.
FileMaker is good but it has more or less stagnated in the past 5 or 6 versions. If their idea of important development is adding new templates then that's a pretty poor indictment of their management and development teams.
FileMaker needs a big update to improve usability, applicability and integrity of data. When I use it I'm constantly worried that I'll make inadvertent edits and not realise due to the lack of any form of change tracking and undo. From what I've read the Go application needs work too.
What we need is a real FCP/Logic Pro X level of rethinking and not just more stagnation-ware updates that do little to enhance the product or address weaknesses.
Apple should really step in and absorb the company and take it over because otherwise I can see FileMaker meeting the same fate.
Of course there are lots of other tools on the PC side and even basic command-line editors to perform some of the work, but I still really want and need a good, native Mac database application that performs well with millions of records for whenever I work in the Mac environment.
Quote:
Originally Posted by Carson O'Genic
We use Bento daily in my laboratory to track inventory. Its simple and cheap and does what we need it to do. Looks like we'll never be updating that computer until it dies.
Reminds me of when I lost the database along with Appleworks. Ugh, Apple -nee Claris - giveth and taketh away.
Filemaker Pro is only $299
Quote:
Originally Posted by Tallest Skil
Dogcow. Claris would be ashamed.
That's why he/she is hiding.
Quote:
Originally Posted by studentx
Executes an SQL query statement for the specified table occurrence within a FileMaker Pro database. This command can be sent to FM via a XML query without having to exporting data from FM to search data.
ExecuteSQL(sqlQuery; fieldSeparator; rowSeparator {;arguments...})
Quote:
Originally Posted by dreyfus2
Now, doing this with queries and/or views is trivial, but ExecuteSQL can only return character-separated values, not true datasets (which e.g. fails immediately with memo fields, as they will often contain the column or row separators specified).
Data Type returned is text not array. If you cannot selectively address the nodes and all you get back is a comma separated list of all fields in a row it doesn't offer very much flexibility.
ExecuteSQL cannot be used with SQL statements that modify data or the database schema
It does only one of the four major commands. (does SELECT, not UPDATE, INSERT, DELETE)
If a database has such poor SQL compliancy why would anyone even mention it?
Is there anything equivalent to Filemaker Go on Android and Win RT?
From what I understand it has been quite popular for developing custom business tools to run on iPads and iPhones and even help adoption of iOS devices in businesses. Despite some of the comments here, I think that Filemaker is not only doing just fine, but its business is booming right now. I would not have any problem finding a job as a Filemaker programmer.
Not everyone needs SQL support and run into those issues. Sure it has its quirks, but is very similar to Hypercard in terms of being easy to deploy relatively powerful solution in a short amount of time.
And BTW the name of the DogCow is Clarus, not Claris. She would be ashamed
Apple's gone too long with iWork on the back shelf - now is a very good time to bring it forward on all platforms - including iCloud. Add in Bento (even if under a different name) and make it a full package.
I can understand that Apple has had a huge focus on iOS development, but the consumer apps in iLife and iWork have been a driving force in Apple selling more Macs over the past decade. No matter how much I love my iPhone it's still the MBP that get the most of my time.
I used FileMaker way back in the early 90s. Since then, I've gone back to it from time to time, but haven't touched it in a few years.
It's a shame because there is a need for a simple database app on both OS X and iOS.
What I don't understand is why can't Apple bring FileMaker back in house and reboot it as follows:
Make it MySQL based. Allow it to either run locally for personal database usage, or connected to a hosted MySQL database.
Allow simple tools for creating buttons, scripts, layouts etc...
Sell inexpensive client versions for iOS, OS X and Windows.
Sell moderately priced producer versions for OS X.
Sell admin/server versions for OS X.
Create an App Store for FileMaker that allows people to sell (or distribute for free) templates or full fledged FileMaker based apps. The producer version could allow the production of native apps for iOS, OS X and Windows that are essentially the client, but tied to specific templates and in some cases specific databases.
The thing, is something like this could be huge in many ways... for example, I'm running all kinds of PHP scripts and MySQL queries all the time to deal with WordPress, it would be awesome to be able to deliver those scripts as apps for iOS, OS X and Windows.
I may be way off base, having not used FileMaker in such a long time, but there does seems to be a need for something to draw people back into it.
Quote:
Originally Posted by macslut
What I don't understand is why can't Apple bring FileMaker back in house and reboot it as follows:
Make it MySQL based. Allow it to either run locally for personal database usage, or connected to a hosted MySQL database.
They can't base their software off of MySql because MySql is owned by Oracle. It is free to use for end users but you cant take MySql code and resell it as your own application.
SQLite would be excellent for a lightweight dB and is already on all Macs, iDevices and built into Safari, and the source code is in the public domain.
I liked the easy methods of Bento and it was far simpler for my wife and kids to use Bento and sync to their iPhones/iPads.
If you are looking for the same type of thing as a replacement you should definitely check out TapForms on the Mac and for iDevices. It is very nice. The costs are pretty good too in comparison to even Bento.
I am switching to that since they added iCould syncing and the Mac OS version.
Still use FileMaker for my heavier lifting database stuff.
PS: what the hell is a "spreadsheet"? I avoid them like the plague. I only use them as an absolute last resort for a very specific task.