Separation Model Behavior Question

[KateJ]

Hi,

I have two files in my solution: one for interface and one for data. All scripts and layouts are in the interface file. Obviously, some of these scripts perform finds on data in the data file. And, more specifically, some of those find scripts perform finds on UNSTORED calcs in the data file. We are an all-Mac OSX company, and we have FM server running on a dedicated machine also running Mac OSX (not OSX Server) with 2g memory. We have about 30 users. The behavior that I am able to replicate is as follows:

1 - Launch the interface file. Perform a script (via a button) that performs a find on an unstored calc (with other find parameters as well). The find results in a incorrect set of records.

2 - Perform the find "manually" on the same unstored calc field. Find is successful (although it does take awhile which is, in my view, normal).

3 - Perform the find via the script again and it works fine. Correct found set is displayed. Script functions properly until the user exits and reenters the system.

Advice from FM Tech Support is that the sep model is the issue here, and that I must perform my find requests in scripts that are in the data file, not in the interface file.

But here's a clincher...the above behavior is NOT replicated when I login to the database (remotely) with a Windows XP machine. The scripted find works fine the FIRST time. Hmmmmm.....

Would love to hear from others on this...especially whether or not FM Tech Support advice sounds correct since I will need to rewrite, etc. several key scripts....

Thanks for any and all input.

Kate

[IdealData]

I'm sure I read something about the way calculations are evaluated differently in client/server situations.

Obviously your interface file is on the client and the data is on the server so you become exposed to this behaviour "defect".

Are all the clients running the same version - latest was 8.03. Maybe that's the Windoze difference?

Maybe the find resultsa re being cached on the client?

As you have inconsistent results then it will be difficult to re-write anything.

HTH

[Fenton]

There was a fairly serious problem/situation with FileMaker 8 versions prior to 8.0v3, having to do with indexes and unstored Finds (something like that). So you must upgrade; it's free for 8. If you still see the issue, the stop the Server files, open them with regular FileMaker, Save a Copy Compacted, and replace current files. At least that worked for a client who was having this problem. Other developers have suggested explicitly turning off indexing for indexed fields, closing Define Database, then reopening and turning them back to what they were.

It was a big deal in the FileMaker community when it was happening. There is a technote at FileMaker support about it, but I can't remember the number.

The good news is that it is fixable, and unstored Finds in 8.0v3 should be relatively speedy, and accurate. At least it worked for them. This was in a separation-of-data solution; so I don't really know what FileMaker Tech Support was saying; maybe some other issue :-?

(P.S. Look at your Find and see if you can use Constrain Find at the end for the unstored part, after narrowing down the found set; makes it much faster.)

[KateJ]

A little clarification....Both files (interface and data) are served by the FM server. No files live on the client machines.

All users are on either 8.0v3 or 8.5v1 (the windows machine I referenced earlier is on 8.0v3). We have some new intel Macs so they have the 8.5 versions; other users are using parts of the system that require a plug-in which is not yet upgraded to 8.5 so they'll stay on 8.0v3 for the time being. Server version is 8.0v4.

And yep, I have rewritten the find requests to use contrain in order to work with a smaller set already. And I've compressed. And I've unindexed....

Oh, and by the way, the find scripts always work fine when I take the files locally -- regardless of FM version, OS or processor chip. So the server has to be involved in this issue somehow!

Kate

[Fenton]

Yikes. It sounds like you've already done everything necessary to fix it; but no luck. All I can say is that my client had the same problem, in a very large separation-of-data solution, on an all-Mac network, and it finally worked, after not working in 8.0v1 (it worked in 8.0v2 I believe, but became too slow to use). Maybe they were just lucky.

There are some technical notes somewhere at FileMaker, about some indexes needing to be rebuilt after upgrading to 8, and about indexes going missing in certain situations. Another diagnostic question is whether these Finds fail on any of the unstored fields, or just some?

[Genx]

I have two files in my solution: one for interface and one for data. All scripts and layouts are in the interface file. Obviously, some of these scripts perform finds on data in the data file. And, more specifically, some of those find scripts perform finds on UNSTORED calcs in the data file.

Seperation model my butt! I had this same issue on an unstored calc... it worked fine until the buggy 8.0v2 update came along and screwed everything to hell -- Make sure ALL your users are on 8.0v3 or 8.5v1 then unindex everything. But... this is the only unstored calc i use so i ended up using a loop script and omit to run through roughly 500 records nightly to do an upload... but the point is I'm 99.95% sure it's one of their updates, because mine was working absolutley fine for about 3 months until I updated some of my clients... and i reported it as a bug to FM Support, and as usual they dismiss everything, and tell you they'll call you back..

[Genx]

Unstored calc i use for searching i mean. P.s. i use the seperation model but my interface files are on users pc's.

[IdealData]

What happens if you execute the find (manually or scripted) in the DATA FILE.

Whilst the calculation is unstored in the interface file this may be due to the fact that it is based on a relationship into the data file, however the data file may (possibly) be stored or even unstored but not due to a relationship.

Just trying to eradicate the relationship from this and move the script in to the data file. Although this won't necessarily get a fix it might solve a little mystery for you and us.

[mscholtz]

Old thread, but just wanted to say I've seen some similar but not exactly the same symptoms. For me, it mostly had to do with related data that wouldn't "refresh" (even in the context of doing finds on it), but I believe I had some problems closer to what you're describing as well.

I definitely had the symptom of it failing to work when hosted, but working when run on the local disk. I resolved that FMS7/8 is buggy enough that I need to do development in a client-server environment, otherwise I can't count on the behavior being consistent when put up on the client's server.

I'm also thinking of abandoning the "separation model".

I too called tech support with no positive result. I think they accused me of doing something "unsupported".

IF anyone else has any further insight into this, I'd still be interested.

[Genx]

Unless you have almost no clue what you're doing, more often than not, it's wise to ignore tech support.

[KateJ]

Well, the long and short of our story is that I did as tech support suggested (moved the find request script steps into the data file) and all has performed fine since. So, as I'm sure others have found, TSM is a great idea, and works well in many instances, but there are times when things don't work right and work arounds are required....

Thanks for everyone's input and help.

Kate