On 7/26/07 2:31 PM, "Kent Swisher" <[EMAIL PROTECTED]> wrote in whole or in part:
> Two things. > > Beverly Voth said: >> Table Occurrences, can be based on related data, so >> you can think of them as "stored procedures" already. > > I always looked at FMP4/5 layouts (using Tango Mac, apple events) as > similar to table views. The FMP7+ table occurance from sql perspective > (using win odbc) is like a table synonym. Yes and no. :D FMP4/5/6 had "tables" and databases and layouts. Using various methods, you could access the "table" (of raw data) sans layout. That got you *everything* (all the fields in that table). Using layout as your access point, often got you just the fields *on* that layout (and that's a good thing, if needed!) Now for FMP7/8/9: You can create multiple tables in a database or one-table-one-database) As Dan says, you can then place a "table occurrence" of the table on the relationship graph. It can even have the same name as the table. This gives you access to the "raw data" in the table. You can also create relationships, so that your "table" is filtered (more like SQL views), then you don't necessarily get all of the rows (which is a *good* thing in FMP and SQL!) The layouts are "tied" to a particular table occurrence (either a raw table, defined as a T.O. or a "filtered table"). ODBC doesn't work with a layout, just the table occurrence. Some other methods of access, will work with the layout, too (thus limiting the fields). Throw in security and you may be further limited, but that's not what we're discussing here. Go with Dan, create ONE table occurrence for EACH table that you will be using with ODBC on a relationship graph. You don't even need to make "relationships" (let SQL make the JOIN). This is IN a new database with no "real" tables, it just has the graph and the T.O. you need. You may have to dig into FMP to see what we mean. Beverly > Dan Stein said: >> If you are going to use ODBC the best way to handle >> this is to create an empty file and pull in the tables >> from your data file into the empty file TO. That way >> you can just have base tables to act on for ODBC. > > Yes, it looks like I will have to go this way. Need to export subset of > Filemaker data to excel file and FTP it. Have FTP part via Witango > working. Was hoping to use filemaker export to create file since it > creates a nice xls spreadsheet that can have custom header and worksheet > name. Noticed the file action in filemaker script is not supported via > the web so even if I could get the XSLT technique to run, it would not > work. Have done the ResultSet to tab delineated file transformation > many a time, but never with data set of 6K records/ 1.5MB file size. > Are there any other tricks to get into true excel format? > > -> Kent > > On 7/26/2007 5:54 AM, Dan Stein wrote: >> All important things to rememeber. especially good advice to read the >> docs a must. >> >> If you are going to use ODBC the best way to handle this is to create an >> empty file and pull in the tables from your data file into the empty >> file TO. That way you can just have base tables to act on for ODBC. >> >> Depending on what your script does you can also run it from this file. >> >> If you want to contact me back channel next week I can help you. >> >> Dan >> -- >> Dan Stein >> >> On Jul 25, 2007, at 9:32 AM, Beverly Voth wrote: >> >>> That's good advice, and Kent, you might understand that "layouts" are now >>> tied to the "table occurrence" (as it appears in the relationship >>> graph) and >>> NOT the tables (although these could have the same name). ODBC calls a >>> particular Table Occurrence, not any given layout. Table Occurrences, >>> can be >>> based on related data, so you can think of them as "stored procedures" >>> already. Or Table Occurrences can show the raw table of data. >>> >>> I never tried "CALL" with FileMaker ODBC, but you might take a look at the >>> documentation on serving FMP with ODBC and see what is allowed. Also, the >>> driver documentation you use may give you other clues to what is allowed. >>> >>> Remember, too, that "password" is no longer the only way to access a >>> database. You have a user AND password (unless you omit the password, >>> but I >>> doubt you'd do that!!) >>> >>> You can make HTTP requests to XML (as Dan suggests) and have -script >>> as part >>> of the call. XSLT may or may not be needed. >>> >>> >>> On 7/24/07 7:59 PM, "Dan Stein" <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> wrote in whole or in part: >>> >>>> I don't have it with me here but you can do it by calling a xSLT >>>> which if you have advanced and XSLT publishing on will call a script. >>>> let me see if I can get someone to send me one. >>>> >>>> Dan >>>> On Jul 24, 2007, at 6:44 PM, Kent Swisher wrote: >>>> >>>>> Ooops, I forgot FMPSA8 can't run scripts on the server. Will have >>>>> to find some other way. >>>>> >>>>> -> Kent >>>>> >>>>> On 7/24/2007 3:32 PM, Kent Swisher wrote: >>>>>> I am attempting to call a stored procedure (script) on Filemaker 8 >>>>>> server advanced (windows) via Witango (windows) direct dbms >>>>>> action. Using ODBC drivers. >>>>>> Found an old post in the archives showing the format for calling a >>>>>> stored procedure for Filemaker 6 was of the form below. >>>>>> CALL stored procedure (a script) statement >>>>>> { CALL script_name ( database_name [ , >>>>>> { layout_name | password } ] ) } >>>>>> Where the outermost curly brackets { } are part of the CALL statement >>>>>> syntax. >>>>>> I have not had any success with this. Since ODBC to FM 7 and >>>>>> above don't know about layouts, I suspect this is part of the >>>>>> problem. >>>>>> Has anybody gotten stored procedure calls to FM7 to work? If so, >>>>>> example of the syntax please. Dan Stein asked the same question >>>>>> in 2004 but no solution was posted. >>>>>> FM8 >>>>>> Witango 5.5 >>>>>> Windows Server 2003 >>>>>> -> Kent Swisher Engineering Tools ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
