The Cartesian join in Filemaker is more commonly interpreted to mean "give every record in this table complete access to every record in that table." But it can perform the kind of build-up you ask for. For example, if you have tables A and B joined by a Cartesian relationship, and you show all records from Table A and export Field A from Table A and Field B (via the Cartesian relationship) from Table B and open the result in Excel you will see that it will have created the list as you describe above - except that it will only show the first instance of the Field A each time.
That can probably be got around, but I've never had to use that characteristic of the feature, so I've never bothered.
Great answer, thanks.
I would never want a product result of two tables (with tableA * TableB rows) like the example I gave above. Cartesian products are always things to be avoided except in very special sitautions -- none of which I've ever encountered.
Seems like FM makes this concept friendlier, which is a good thing.
A key difference between Filemaker and more typical SQL based systems is that in the other systems, you use a SQL query to set up what is essentially a "virtual table" for a given form or layout. FileMaker layouts are based on a single physical table as specified by the table occurrence listed in "show records from". Thus, in Access and other systems, using a cartesian join in the Query for a report or form produces a record set of 100 records in your example. In FileMaker, the layout is based on either one table or the other, but not both as it is not based on any join at all. Thus, it has a found set of just 10 records, but a portal to the related table will list all 10 records of the other table no matter which record is current on the layout.
This may make cartesian joins a useful problem solver rather than poor relational design to be avoided, but this approach also shows up as a limitation in other cases. Consder trying to produce a list type report based on an outer join in Filemaker, for example of something very simple to do in SQL that is not at all simple to produce in FileMaker.
Thanks for another one of your excellent replies. :)
Your knowledge of this product is simply amazing.
Of all the things in all the world that I want Filemaker to add to the product, the ability to create a listing of 100 x 1,000 = 100,000 records is just below button-driven tooth extraction. So: if I find that FM13 has that in its feature set, I'll know where to come looking...
I don't need it for cartesian joins, but the same approach supports outer joins, union queries, cross tabs...--which are quite useful. And just because we might gain the ability to do something silly as a side effect of getting something more flexible and powerful than the current approach doesn't mean we have to go ahead and do that silly thing...
Are you saying you would like some type of way to generate test data easily?
If so, currently, you'd write a script to do that, right?
Perhaps I missed your point.
Sorry, Mork, I was being sarcastic. At the risk of sounding argumentative, I have never felt any urge to see SQL implemented further within Filemaker. It is amazingly useful to allow the sharing of data between applications - ODBC and SQL from MySQL to Filemaker, from 4D to Excel - absolutely brilliant. But extracting filtered, sorted, data from a cross-table query is like. Watching. Paint. Dry.
Having to write all that code? It just feels like I should be doing it in a kipper tie and flared trousers by the light of a lava lamp. Thank goodness FM and Excel come with decent SQL Wizards to help me write the stuff. And surely it was SQL that the guy had in mind when he said "The great thing about Standards is there are so many of them." The number of times that I've written a Query exactly like the book says, only to find it doesn't work because my Query didn't read the same book as me, apparently. And Heaven help you if you put a space in the wrong place.
There are many features that I would like the Filemaker engineers to provide me with, but the ability to turn a table of 100 records and another of 1,000 into an output of 100,000 records doesn't even feature on my Wish List.
As Phil says, though, there may well be other Seriously Big Advantages come alongside that ability; maybe I just have no imagination, but so far I haven't realised what they might be.
That said, I've signed up for next week's FM Academy's webinar on the newly-added ExecuteSQL script step, so maybe they'll show me what I've been too blind to see.
I've come at this from the exact opposite perspective: I've been doing SQL for 20 years and can't imagine not having that incredible power at my finger tips in any database. I spend most of my day using Java with Oracle back-ends.
I like the way FM does things (I still haven't bought it <s>), but I feel like I'd be giving up a lot of power. FM would be perfect for me if it also included a SQL window where I could just enter queries for the local database of any complexity. Maybe I wouldn't do that all the time, but there are times when I don't need a layout, I just want to see a few resultsets.
With folks like you and Phil on this forum, however, most, if not all, of the FM problems I might run into could be quickly solved. :)
Please post back with your thoughts on the ExecuteSQL webinar.
I don't know if this can be helpful for you or not, but here is how I set up my tables and my layouts in Filemaker.
When I make a table I'll always add "Tbl" in front of the name. So for instance a table of clients would be called TblClients.
Filemaker automatically makes you a layout for this called TblClients.
Now if I want to make a layout for the user I'll create a new one called LayClients.
And I always put my layouts and my tables in two seperate folders.
That way the user interacts with the LayClients. But I can go into the TblClients and see the raw data. I can interact with it if I quickly want to look something up or if I want to try stuff out.
You can go in table view or create a layout for yourself in form view.
Anyway, try it out, it's pretty handy sometimes.