2 questions: IWP, and indexing

I have a FMP8 server (Mac) and mac clients. The database is for a
school, and they want teacher access through IWP. It's all set up and
works well except for one thing. I'm getting strange behavior when
using GTRR script steps in the web interface.

The file has a simple relationship between student and enrollment
(student primary, enrollment has foreign key of the student's
primary). I have a portal on the student layout that shows enrollment
records, and has a button on each portal row to go to related
enrollment record on a dedicated (enrollment table) layout. This
works perfectly in FM. On the web, clicking ANY portal row goes to
only one of the related records (always the same one for a given
student). I have tooltips turned on for this button, with a
conditional label showing the record it should go to. This tooltip
always shows the ACTUAL record it will go to: in FM it shows the
individual record, the way it's supposed to work (and does work) - but
in IWP it shows the SAME record name for every one of the rows. This
is baffling me. It seems like the relationship is getting twisted by
IWP, yet I've read that FM does a very good job of translating those
relationships in the HTML. Does anyone have experience with this?

Note: there are some layouts where a similar setup DOES work over
IWP. And some layouts where it's ALWAYS broken. It's consistent.

2nd question. Perhaps related? I've had trouble over the past couple
of years with indexes in FMP. They seem to accumulate old indexing
info and then start yielding irregular and inaccurate 'find' results
(and this happens even with the 'create indexes as needed' option).
Is this a generally acknowledged issue, or do I need to do some kind
of file maintenance that I'm unaware of? Is there any way of cleaning
the indexes? What I've been reduced to, when I start noticing an
anomaly, is to turn off indexing for a field, then turn it back on.
Any helpful hints?

And finally (I know I only said two questions, but a 3rd popped into
my head) - what does the 'clear cache' script step do? I couldn't
find info on it anywhere, and was hoping it would solve question #2.

thanks all,
Lanse

Re: 2 questions: IWP, and indexing

On Oct 17, 12:27 pm, lansingoogle wrote:
> I have a FMP8 server (Mac) and mac clients. The database is for a
> school, and they want teacher access through IWP. It's all set up and
> works well except for one thing. I'm getting strange behavior when
> using GTRR script steps in the web interface.
>
> The file has a simple relationship between student and enrollment
> (student primary, enrollment has foreign key of the student's
> primary). I have a portal on the student layout that shows enrollment
> records, and has a button on each portal row to go to related
> enrollment record on a dedicated (enrollment table) layout. This
> works perfectly in FM. On the web, clicking ANY portal row goes to
> only one of the related records (always the same one for a given
> student). I have tooltips turned on for this button, with a
> conditional label showing the record it should go to. This tooltip
> always shows the ACTUAL record it will go to: in FM it shows the
> individual record, the way it's supposed to work (and does work) - but
> in IWP it shows the SAME record name for every one of the rows. This
> is baffling me. It seems like the relationship is getting twisted by
> IWP, yet I've read that FM does a very good job of translating those
> relationships in the HTML. Does anyone have experience with this?

1) Try it with a couple different browsers and confirm its not a
particular browser/version giving you the issue. In particular try it
in Safari, IE7, IE6, and Firefox.

2) Element overlap and layering in particular sometimes workout wonky
in html. Try making the portal rows a little bigger, make sure the
button isn't over lapping anything, and put the button on top. Try re-
making the layout from scratch it could be some clutter somewhere on
the layout that's mucking it up on the web.

> Note: there are some layouts where a similar setup DOES work over
> IWP. And some layouts where it's ALWAYS broken. It's consistent.

See number 2 above. Its probably either some clutter on the layout, or
an overlap/layering issue that's confusing it. (And possibly only is a
problem on one browser. Shuffling things around a bit should resolve
it.)

> 2nd question. Perhaps related? I've had trouble over the past couple
> of years with indexes in FMP. They seem to accumulate old indexing
> info and then start yielding irregular and inaccurate 'find' results
> (and this happens even with the 'create indexes as needed' option).
> Is this a generally acknowledged issue, or do I need to do some kind
> of file maintenance that I'm unaware of? Is there any way of cleaning
> the indexes? What I've been reduced to, when I start noticing an
> anomaly, is to turn off indexing for a field, then turn it back on.
> Any helpful hints?

This shouldn't be happening. Its possible your files are damaged.
Weird things also sometimes happen when you store only text in numeric
fields, or use odd character sets.

Removing the indexes, compacting the file, and recreating them won't
hurt and might resolve the issue. But the ideal solution is to export
the data to plain text, and import it into those 'never crashed,
corruption free, completely pristine empty clone backup files you have
on hand. (Except pretty much nobody ever actually has these.)

Worst case, export the data to plain text, recreate the file, and all
its layouts, scripts, and field defs from scratch, and then import the
data.


> And finally (I know I only said two questions, but a 3rd popped into
> my head) - what does the 'clear cache' script step do? I couldn't
> find info on it anywhere, and was hoping it would solve question #2.

Per the FM help

"This script step is not web-compatible."

"Flush Cache to Disk performs an immediate flush of the FileMaker Pro
internal disk cache to the computer's hard disk. This operation is
normally done periodically during idle time and after extensive
structural changes, such as converting files and defining fields."

I've -never- needed this functionality.

Without getting into the gory technical and theoretical details of
disk caching, suffice it to say that anything in the disk cache can
generally be considered as good as being on the disk.

The only time it would matter is if you accessed the files directly
with other software. They'd see the files as they were on the disk,
and not anything pending in filemakers cache. So if you ran 3rd party
backups on the open files without flushing the cache, you'd be risking
not getting the most up to date information. But really, you shouldn't
be backing up open filemaker databases anyway. (for example I might
use filemaker server's backup functionality to make backups on a 2nd
internal hard disk, and then have 3rd party software back those up to
dvd etc.)

The only other time it would matter is if you had a power failure, in
which case the internal cache would never get written. But there are
better ways to cope with the risk of power failure than to stuff your
database with flush cache commands and hope for the best.

-cheers,
dave