For anyone reading this that doesn’t make it to the other thread. The $50 comment was a mistake, and is not the amount.
As I stated above: when an announcement is to be made, a professional, self-respecting organisation should publish its own written statement in sufficient detail in a timely manner.
And it is not off the table that the on-premise option will disappear or suffer an even steeper price hike in the near future.
While not trying to make excuses, it would be fair to recognize that Claris was not the only company involved. Much of this rebranding was handled by a third-party marketing company. Between the 3 sets of hands, a mistake could easily be made.
Can you be gracious enough to forgive that, and move on knowing that datapoint was an error?
Awaiting confirmation that this was a communication blunder.
If the information proofs accurate its all due course. No mistake, nothing to forgive.
I imagine, unless you are close to someone at Claris that actually knows, this is all you are going to get. And I doubt your sales rep would actually have that kind of information.
https://my.filemakers.community/t/big-announcements-from-fmi/250/41?u=jormond
Yes, expectations are low.
The good news is that my source is solid… So take that as you will, and sleep well tonight. 
Thank you, have a good night, too.
THANK YOU Josh for making this clarification. 99.9% of me felt this had to be a case of “fake news”
I assure you, I had a bad reaction to it also. Mine was just more private-ish.
reading through thees postings, I think I’ll wait for clarification from an official site
Going ‘cloud’, paying that much (if true) - would not be good. Really not good
At least for now, it is not possible to store sensitive data (health system) on servers in foreign countries
A bad taste remains. Re-branding is always problematic, a sign that something went not the way somebody expected… Also the whole ‘workspace innovation thing’ sounds strange here, people are thinking that filemaker failed to compete on ‘official’ disciplines and therefore searched for an own island…
1 Like
@jormond I know you’re a dedicated FMI evangelical, but looking at SQL, it’s easy to get confused exactly what FMP is trying to get us to believe. The “not a SQL database” comes up most often when FMP can’t keep up with simple queries that hang the machine (GROUP BY, for example).
To wit:
FMP has SQL. FMP has JDBC (which includes SELECT, INSERT, DELETE, and UPDATE).
FMI publishes a SQL reference manual.
- FMP has third-party plug-ins that implement SQL. *
*Additionally, I’ve written (Java/JDBC) sync utilities using tons of SQL to move data back and forth between FMP and MySQL and between FMP and Oracle. *
FMP’s JDBC driver also supports DBMetaData classes so you can dynamically determine field types and such. In my view, FMP’s SQL support (but not performance) is good.
So, what exactly makes a product “SQL?”
–
The problem is that FMP’s SQL isn’t truly SQL but hacked on top of FMP’s Find. Thus, anything that the company can do to make SQL real and be like other relational database products would be welcome from my point of view.
1 Like
I got feedback that the information printed in the article is not entirely accurate, as per now.
A more humble style of communication would be very helpful to all.
1 Like
And? We are still talking apples and oranges. Your arguments still lead to the exact place every developer gets to when evaluating a project. Is this the right tool for the job at hand.
SQL is not necessary in most cases. Built on FM’s strengths, a project can support many users and perform really well. It isn’t until you get to really high end needs, like your example of handling 20 million calculations in less than a second, that FileMaker can’t perform as well as other options. So you would use a different tool for that. But in 13 years of development, do you know how many times I’ve need to handle that many calculations or that heavy of a load? Not once. So the argument is out of scope.
SQL in FileMaker is good for a few things. Use it for those things. Don’t use it for what it’s not intended for. Your description of FileMaker’s SQL calls are not a surprise to anyone. We have honestly and careful talked about proper use-cases for as long as SQL has been in the product.
I’ve never tried to advocate for FileMaker in a space it doesn’t belong. However, I will continue to balance the conversation anytime people try to make FileMaker look bad with wide-sweeping or out of scope arguments like I see above.
2 Likes
I tried to list the many cases where FMI promotes SQL. Evidence, not trying to make FileMaker look bad. Jeez.
Can you find a single place in any FMI documentation that states: “FileMaker is not a SQL Database?”
I have not been able to.
1 Like
When the feature was introduced, at every under the hood session where this question is asked…same response. You chose to continue make this argument. SQL runs on top of the Draco engine, so it is always going to be slower than other FM methods.
1 Like
I still don't think they will switch to an SQL backend, but it looks like Claris surprised us both in its most recent product roadmap by including an Android client. Claris is still an Apple company, but I guess they are really looking for all the different ways they can get new revenues and revenue streams.
That must also mean Apple is ok with all that (not just the Android part, but mostly the business diversification to seek growth). Now I hope they will pour in the money it takes to have all those initiatives side-by-side and not just dial down on one thing to focus on another. I can trust the revenue will follow, it will still take some time before they get to collect the fruits of those efforts.
I don't know what are the mechanism one can seek for Apple to inject money into a specific business case, but I think they have a valid case to play (not talking about the money it took to buy Stamplay, that was a catalyst, not a 'let's make things happen' expense)
Yup. Big stuff. And I’m sure this isn’t the end of it. The injection of outside eyes, and views, can have a big impact. Hopefully they diverge too much from the “FileMaker-ness” of the platform. But it will be great to see the shifting of gears and getting things moving.
I wish FMI would just borrow the Core Data stack from Apple. In Core Data, defining schema and relationships is visually different, but no more difficult than FileMaker. You get the "broadcast" stuff for free. You just tell ViewControllers they should listen for changes to the context (store workspace). When the context has changes, the UI refreshes and does the necessary insert/delete calls, with animations.
I can wire up a TableView or CollectionView this way in 5, maybe 10 minutes.
All the way under the hood (the stuff you never touch), the store itself, is SQLite. It can be other store types like XML, etc. but usually isn't. Working with objects is easy, no matter what the store type is, you use the same high-level Core Data calls like:
let artist = Artist(context: background)
artist.name = "Brian"
background.save()
When you call save, the PersistentStoreCoordinator turns that into to a SQL (etc) statement, executes that against the PersistentStore, writes changes to background, which then triggers a UI update. All of this behavior is free.
Like you, I've seen LiveCode, Haploo, and Xojo folks try to rebuild the Core Data stack, and I'm like, "Why? This problem was solved back in iOS 3/macOS 10.4". 
4 Likes
Rosemary Tietge has posted news about changes to the FileMaker Community forums today https://community.filemaker.com/en/s/question/0D50H00007dVmH8/community-updates-and-coming-changes?s1oid=00Di0000000eyqY&OpenCommentForEdit=1&s1nid=0DB0H000000fxYs&emkind=chatterPostNotification&s1uid=0050H00000Bq9fa&emtm=1580308638643&fromEmail=1&s1ext=0
They have a contractor on the job: Matt Brown. They say that they are about to roll out improved search in the next few days and other changes throughout February.
This paragaph is interesting. I wonder which open source project they are going to use?
They will also be making many page components open source in the coming months. This may give us options to fix long thread pagination. Once the code is accessible, we will look for ways to change it to make reading and navigating long threads easier.
1 Like