Jump to content

Something to be aware of


-Queue-
 Share

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

Recommended Posts

If you don't use a Commit Records/Requests script step after a Set Field step, FM 7 will not exit the record, even if you weren't in it to begin with. This is much different than previous versions where you could take it for granted that a refresh would be forced as long as you didn't use a Go to Field [field] step in your script and had forced an exit of the record at the beginning of the script. I've only converted one file and this new feature caused it to be flaky.

Version: v5.x

Platform: Windows 2000

Link to comment
Share on other sites

Something else...

Here are two files: a sample fp5 file using a repeating field for a value list, filtered by a self-relationship by id and the same file converted to fp7. Notice the value list is broken since the relationship graph displays the self-relationship as many-to-many. Can this be fixed or am I screwed?

vltest.zip

Link to comment
Share on other sites

RE: Commit Record/Request with Set Field [] ... This new feature explains probably 80% of my unpredictable script behaviors, JT. Thanks for filling us in on it. Let's hope that, once we understand how to creatively utilize it, it will indeed be a benefit and not just more work adding another script-step. I'll try to remain optimistic and believe the former.

Version: FMP 6v4, Developer 6, Server 5

Platform: Win XP, 98, 2000

Link to comment
Share on other sites

You got me on that one...I looked at both the files works what you did in v6.04 but not in 7 as built. Anyone else want to take a crack at it? This might be a case of behavior difference between versions. I'm sure many "expected" behavior issues will be brought up. I will tinker some more with it and post back if I can get it to act the same way for you. Is this a method that you use in your solutions or something that popped up as you were test driving FM7?

Version: Developer v7

Platform: Mac OS X Panther

Link to comment
Share on other sites

It's a method I use quite frequently, in nearly every other file sample I post here. It seems to have been obliterated, unless there's a 'workaround' for it. I even tried creating a separate table with only an id related to the main table and the repetition field. It works fine if you use 'Include all values', but I want it to be unique to the self-relationship. If I specify to only use related values, then it only gives me the first repetition; otherwise it acts as a constant relationship and gives me all the repetitions in every record, even though they're not related based on the id to id relationship.

I guess I could go around this by hard coding all the reps into one calc, but that destroys the simplicity and dynamics of using repeating calcs. frown.gif

Link to comment
Share on other sites

Well, it seems the only work around is to define the repeating calculation as usual, then to create a field that concatenates them, e.g. repfield[1] & "

Link to comment
Share on other sites

This workaround does not take order into account. The value list will still sort alphabetically. It appears there is no way anymore to force this nifty technique to work. Thanks, FileMaker, you've ensured I won't be updating my systems anytime soon, if ever.

Link to comment
Share on other sites

I'd respectfully suggest that you're missing the forest for the trees.

The new structure allows you to create separate TABLES to hold your custom value lists, and do away with kluges like this forever. Just create a new table with two fields: Id and value - each value is a new row (record).

I mean, you could have always done it this way with previous versions, but then you needed to make a separate file for the table, which was a huge PITA in all kinds of ways. Now you can do it the way the rest of the world has always done it.

Don't get me wrong - I have my gripes about FM7. But this isn't one of them.

Link to comment
Share on other sites

I think you're missing the point. If you don't specify a relationship, then FileMaker 7 uses all values for the repeating field in all records, as it should; if you do specify a relationship, then it only uses the first repetition in the related record. This is highly inconsistent. To get around this limitation, I've created a separate table containing the exact number of records as would have been repetitions. This requires adding a script that modifies all records in that table in order to perform a triggered lookup, as opposed to an automatic one in the current table that's triggered by changing a global and looks up a repeating calculation to index all values nicely. And to make it multi-user compatible, X number of related records would have to be created for each new record in the main table, where X is the number of repetitions necessary in previous versions. It's not a custom value list; it's a dynamic value list, which apparently is going to be much more difficult to create in FM 7.

One record, one repeating calculation with 53 reps, a trigger field to relookup the calc into an indexed rep field, and a valuelist based on a self-relationship replaced by an extra table, 53 records per number of records in main table, a trigger field to relookup one calculation for each of the 53 records, a script to go to the related table and force this relookup by modifying the 53 records, and a value list based on the related field...

I wouldn't definitely call the second technique a kludge; the first is simple, compact, and efficient. The second is a real pita and completely inefficient.

Link to comment
Share on other sites

Thanks JT,

You just give me the 4th reason why I won't move quickly to 7. This even calm down my anger for the OS9 issue.

I use this technique a lot actually too, and I can see the weaknesses.

Now, I don't get why it doesn't work. It seems like this is some indexing issue, as if FileMaker had changed the way indexing works.

Surely you already tried it, but what is the result given by the ValueListItems( ) in an unstored calc ?

Link to comment
Share on other sites

It doesn't make sense though that using all values works and treats repetitions the same way it does carriage-return separated lists, but using only related values ignores all repetitions and treats the field as if it were regular. It should be either one way or the other, not dependent upon the type of value list. Putting the related repeating field on the layout displays all repetitions, so why shouldn't a value list based on it do the same?

Link to comment
Share on other sites

  • 6 months later...
  • 3 months later...

Oh well...

Again, not that I'm using it a lot.

FieldRep 1 = Mr, Dr, Pr, etc.

FieldRep 2 = Mister, Doctor, Professor.

With 6 you could have made a value list combining both fields to get

Mr Mister

Dr Doctor

Pr Professor

Well, it doesn't work anymore with 7.

Link to comment
Share on other sites

That does suck also, since you can't sort a value list based on a repeating index field anymore. So, how to keep a repeating calc based on a parsed text field (e.g. path name) in correct order when defining it as a value list? Any ideas?

Link to comment
Share on other sites

See the solution I posted in this thread. It sorts using the repeating index field, instead of using the default alphabetical one. The same solution in v7 results in the first word being repeated instead of each item of the value list being combined.

Link to comment
Share on other sites

Talking about the original topic, another issue I have run into is that when working with Portals, if I don't use the Commit records before starting a loop, many times it will not Goto the first portal row.

I've spent 1 whole day fixing this in all of my scripts. MAJOR PITA.

d-oh.gif

Link to comment
Share on other sites

This topic is 6194 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
 Share

×
×
  • Create New...

Important Information

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