hi all
(windows, server 8, clients 8.5)

I have just upgraded from v4 to v8, and the replace command now has
problems.
If a user is in a record, then it is locked, and the replace command
says "3 records were locked and were not updated".

I accept this as sensible as the records are in use. But it leaves me
a bit puzzled.

1. the records are not really in use, they are not being edited by the
user. It is just by chance that for some reason the cursor is being
left in fields on certain forms. This is often not due to a user
action but due to a copy or paste script step.

Q.can we force the user out of the record?

Q.can a record automatically be 'committed' when the form loses focus?
(coming from v3 originally, this solution has 50 files rather than 1
file with 50 tables)

2.if we can't force the cursor out of a record, can the replace
command let me know which records couldn't be updated? - it must know.

finally - startup time on server4 was 1 minute. startup time on
server8 it 2.5 minutes. what gives?

cheers

Tim

On Mar 21, 4:39 am, "Tim" <tswal... (AT) gmail (DOT) com> wrote:
Change your scripts so this doesn't happen.




You may want to look at your db structure. Do you really need 50
tables?

You can script navigation to force a record commit.



No. You can script the replace with a Loop and Set Field and capture
the errors though.

successive editions of Filemaker have been successively slower.

DJ

thanks for your comments,

yes I do need 50 tables.
this applications runs every aspect of a multi-million £ company, and
has done for 10 years!

we have tables for products, customers, orders, rotas, packing,
shipping, financial, warehouse locations, buying lists, daily
reconciliation, order backups, customer backups, stock movements etc
etc. This is a big application!

On Mar 21, 12:00 pm, "Tim" <tswal... (AT) gmail (DOT) com> wrote:
Heh, 50 tables isn't a shocker for me, I have 80, I also run a whole
company with it. If it were even close to fully normalized I would
have a lot more tables, let me tell you! I use too many value lists
that should be tables.

But to offer some help to the OP: I recommend setting up scripts and
layouts to edit records rather than letting your lusers just click
into fields and leaving the cursor blinking in there after they are
done editing while they go browse NCAA results.

- Make your View layouts not have editable fields.
- make Edit layouts where the fields are editable.
- Make Edit scripts that take the lusers to the Edit layouts and wait
in Pause mode for a determined-by-you period of time

Of course this will be impossible to implement all at once, but start
doing it for those tables where you are most seeing your record
locking problem, then you can expand from there if desired.

BUT I have to ask this question: How is it that this problem didn't
exist in v4??? Maybe it existed but you weren't getting the helpful
message? I can't think of what would be different in the current
version that would cause this problem to start unless you need to add
some "Commit Record" steps in your scripts (as I have been doing for
about 3 months, thanks FMI).

Tim wrote:
This should actually be less of an issue in FM8 than it was in FM4. In
FM4, just having your cursor in a field locked the record. In FM8, you
can click into a field but the record doesn't get locked until an edit
is made. If you are using copy and paste script steps, I would question
why; I can think of very, very few instances where you should use these
steps rather then a Set Field step. Nonetheless, the copy step will not
lock a record in FM8 as it did in FM4. And if you follow the paste step
with a Commit Record step, then the record will be exited and all is well.


No.


No.


See Grip's suggestion about a looped Set Field.


If you haven't already done so, try closing FM Server and then opening
the files directly in FM Pro 8. This in itself might resolve the
startup slowness issue when you go to re-open the files on FM Server.
You might also try 'save as compressed' while you have the files on FM Pro.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Associate Member, FileMaker Solutions Alliance

Oh sorry, one more thing:

Regarding opening times. I agree completely with Tim that each new
version is slower than its replacement.

It's been so long since I used v4 that I can't remember how fast it
was so I'm hoping not to see such a dramatic time increase as you saw
in going from v4 to v8, but let me offer this:

I recommend not having your solution open every single file whenever a
user starts it (which it sounds like you are doing). In fact, it comes
to my mind that maybe that's why you have exactly 50 files...your
users can't open any more than that before v8! As I said up there, I
have 80+ files and I have not once had a user complain that he
couldn't open something due to having more than 50 files open (I'm
still in v5.5/6)

I recommend letting FM open the files it needs when it needs them,
especially in a large, company-wide solution like we have.

Your users are often going to be working in a limited number of tables
for a given work task, or a given set of the day's work tasks even, so
just let FM handle it. Opening files that are not going to be used it
totally wasting resources (time, network, memory)

I recommend this even higher with v8 since it doesn't bring up that
annoying "Opening File Such and Such from server blah-blah-blah"
window anymore.