Processing rows in a table

[lando]

A question (perhaps the first of many) I want to be certain that a script is processing the table of my choice. So, Is there a way to "point" or "use" a table that I want a script to affect?

Let's say I have two tables - unrelated.

ALPHA and BETA.

I process all of the rows in ALPHA by entering an "X" into a field called "TAG". Now I want the script to do the same thing to all the rows in BETA.

How would I do this in a script? Is there a script step (or series of them) that would help?

[mr_vodka]

You will have to go to a layout that reflects a table occurrence of Table BETA. The field does not have to be on the layout if you use Set Field []

[lando]

Thanks for the reply. I was hoping to not have to not have to refer to a layout for either table. Is that possible?

[mr_vodka]

Perhaps through ODBC. What is your resistence to going to a layout?

[lando]

Resistance is futile... This is more of a quest for simplicity. I am used to processing tables directly (no layouts or forms) and wanted to see if FM's scripting language could do it. If I have to use a layout, that is fine - just so long as I know it is the most efficient method offered. Thanks again.

[LaRetta]

Hi lando, welcome to FM Forums!!!

I would wonder why you 1) flag a field (it is not multi-user dependable) and 2) have duplicate entries in table A and table B. IF the tables are related, you can use Replace Field Contents to flag the related records (matching the found set of Table A). The issue is this ... filemaker fires scripts according to the perspective of the table occurrence of the layout it is on. This is very good. So you can set fields in related tables based upon the current parent records.

As John asks, what's the problem with layouts? EVERYTHING in FileMaker MUST take place based upon a layout (which is in a window). This is powerful because a window can be focused upon and actions happen in many different ways. But truly, these types of theoretical scenarios are of little benefit because, what is possible in one configuration is not possible in another. And there are dangers involved in blanket statements of usability because we are throwing darts at a VERY large dartboard.

LaRetta :wink2:

[David Jondreau]

You might be able import to Alpha to achieve this.

[Fitch]

Import is context-sensitive too. Resistance is futile... you will be assimilated!

Orlando, I'm with you. I'd love a "Set context" script step.

[David Jondreau]

I will resist!

Are you sure? I haven't done a lot of importing, but I thought I didn't need a Go To Layout[] step before an import.

[comment]

Which table are you importing into, then?

[David Jondreau]

The one I defined as the target table in the Import[] script step.

Isn't that what's happening in this sample file?

User:Admin

Pass (Null)

PS: Ignore the fields in the table mysandbox, they don't apply to this example.

mysandbox.fp7.zip

Edited July 25, 2008 by Guest

[comment]

That's interesting - I didn't notice you could do this (you can't if you import out of script).

[David Jondreau]

Just call me Locutus.

[Fitch]

Good call, DJ. Forgot about that one.

[lando]

Thanks for the feedback everyone. This is all very interesting. If I understand you all correctly, i will need to refer to a layout that contains the target table if I want to process a set of rows in that table.

Since I am interested in processing the table with no user input at all, does the layout have to have any fields at all? Can a layout be hidden from users?

Hmmm... FM should have a better way of processing tables programatically. I hate to say this but that other database software that starts with an "A" can do this. Sorry, sorry blasphemy, I know.

[Fenton]

You want the layout in order to provide the "context" for what you're doing, loop thru the records, set local fields, etc.. Actually, it would be possible to do it without a layout, but usually slower, more work, hence not worth the trouble.*

No, the layout likely doesn't need any fields on it; except then you can't see when troubleshooting; and really it makes no real difference if a few fields are there or not. I've seen too many files where a beginner developer had all kinds of layouts (too many), but no simple developer troubleshooting layout, PITA.

Yes, you can hide a layout from users. No, they don't need to see it while the script is running, if you use Freeze Window, and do not use steps that force a refresh of the window (which are very few).

It's not so much that what you're saying is "blasphemy." I for one appreciate accurate criticisms of FileMaker's weaknesses. But saying things like "FileMaker should have a better way" when you're still learning to use it doesn't really make much sense.

Yes, FileMaker uses structure more than other databases. Yes, sometimes you might wish it was more like "programming." But structure is also one of the main reasons FileMaker is easier to use than other databases. It most cases it is just a different paradigm (whatever that means -). I think you will find that the basic logic of relational design and operations are the same.

*You could gather the unique IDs somehow (various methods), then Loop thru them, setting them one at a time into a global field, then using that in a relationship to set values in the target table; requires no layout of that table. There are some cases where this is desired, but not often.

[P.S. Tip. Use a Form View layout (or switch to Form View) when running an operation over lots of records. It is faster than a List View layout. This is partly because of the window's scroll bar, which must be checked and moved in a list view. Don't know how true this is anymore, been doing it for years.]

Edited July 27, 2008 by Guest

[LaRetta]

I hate to say this but that other database software that starts with an "A" can do this.

Every database has things it can do that the others can't. I spent 8 years working with the "A" software and it sucks compared to FileMaker.

I use FileMaker because it is the most versitile; cross platform; and rapid-development tool I have ever seen.

LaRetta

[comment]

Every database has things it can do that the others can't.

True, and I'm sure Access (what's the secret?) can even do some REAL things that Filemaker cannot. Addressing a table with no layout doesn't seem like a "feature" to me.

[lando]

Success!!! Thank you all. I did what I wanted to do and it was easily done once I got the idea of using layouts through my thick head.