Jump to content

Querying a filemaker db with SQL


This topic is 3169 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

Hi, I am in the process of building a databse in access and I've been told that filemaker would be much better solution. I am fairly used to SQL server 2012 so one of my main concerns is being able to write SQL to manipulate my data and build the relationships and keys etc. Is this all done in a GUI in filemaker? I know it can be connected to SQL server or oracle but (forgive my ignorance of filemaker) why would I need filemaker, other than to build something at the front end. If I could just make selections without a full functionaly in filemaker I think this would be ok for this project. If anyone has any comments that would be great!

 

Thanks 

Link to comment
Share on other sites

In FileMaker you use a GUI for building tables / cols / relationships.

You also use a GUI for building layouts for user interaction with the data layer.

It's a distinctly different paradigm than Access or SQL Server so consider the learning curve as a significant part of the equation.

In a simplified description FM is a development environment where gui is bound to data layer and a scripting language knits the two together to facilitate building functionality for the user.

Using FM as a strictly front end tool for a SQL back end can be done but is probably not the best choice as performing CRUD transactions or finds/sorts with SQL as a back end on large data sets will cause performance issues.

Not saying you shoudn't do it but I would not approach this as a beginner.

IMHO making a decision on any development platform after a brief introduction and no platform SME at the table is more about what is the team comfortable with than anything else. Furthermore making a platform decision based on a coworker suggestion is equally fraught with risk.

Edited by Kris M
Link to comment
Share on other sites

FMI actually actively warns against using FM as nothing but a front-end to an ESS SQL database.

As to creating tables through SQL: sure, FM supports that.  But not setting up relationships.  That is done through the FM UI

Link to comment
Share on other sites

As i said - "It's a distinctly different paradigm than Access or SQL Server so consider the learning curve as a significant part of the equation."

SQL Queries are part of the learning curve/paradigm shift as the relationships graph in FM can be thought of as a gui based query builder.

Edited by Kris M
Link to comment
Share on other sites

can you make selections from the database using queries?

Yes and no. You can make SQL selections using SQL queries. You cannot create a Filemaker found set using an SQL query - at least not directly. Filemaker supports a limited set of SQL, but it's not an SQL database at its core.

 

OK, thanks, a final related question, is that gui basis as flexible as writing queries, i.e. can make selections that are as specific as a written query ?

Yes.

Edited by comment
Link to comment
Share on other sites

  • 3 weeks later...

FMI actually actively warns against using FM as nothing but a front-end to an ESS SQL database.

As to creating tables through SQL: sure, FM supports that.  But not setting up relationships.  That is done through the FM UI

Actually, the point here I believe, is that FMP is not the best tool for executing high volumes of transactions form many users to a SQL database. However when same workgroup needs to work with large volumes of data, and updates are infrequent I have found " FM as nothing but a front-end to an ESS SQL database."  to be a very effective approach, for several reasons

-- Searches can be very much faster

-- Complex calculations and /or aggregations across many tables,  can be very fast using views set up in SQL. You create views that provide "Virtual Flat Tables" of aggregate values. Dramatically fast vs native FM - especially over a WAN.

-- Publishing SQL to the web is very scalable using PHP or other tools, and subcontractors to do this are easy to find.

So in a  write "a few times an hour" read "millions of times", scenario ESS is in fact brilliant.

 

You do have to learn (by experience, unfortunately) the behavior of "Flush Cached External Data" - I have found that to be certain that you are looking at the most current data this has to be done in the "context" of each table that could have been updated - not just in the layout you are looking at. A bit cumbersome.

Tools expressly designed for SQL front-ending deal with things like this,  and also avoiding "collisions" where multiple users are trying to write to the same record, much better.

Link to comment
Share on other sites

The FTS Advanced book (http://www.filemaker.com/learning/training/fts.html#fts-adv), in chapter 9 - Integration, has a pretty good list of things that behave differently when interacting with an ESS table vs a native FM table.  It is must-read material for anyone who is used to working only with FM native tables.

Link to comment
Share on other sites

This topic is 3169 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.