I have this relational database that the user jump around in.

Let's say the user is sitting at a new record screen on file A, but they
need to jump to another screen and look up another record on file B.

Filemaker won't let them jump until the new record is filled out
completely. So I let the user delete the blank record and they go on
their merry way.  

This creates a problem in that they can also delete a previously created
and complete record.

The solution, If I knew how, would be;

If this record has a value in field 'X' it is not delete-able except by
a supervisor.

OR;

a person with this password can only delete empty records.

HELP!!!  I have smart-ass users deleting records!  But if I restrict
them, they cannot jump from one screen to another with completing the
first screen. :(

Jason

You need a little more thought in your user-interface issues. Why are
users having to look up info they can't access from file A to complete a
new record?  Bad design.

Why not give the users a portal or a value list in File A that shows
them the data they're trying to look up in B?  Why not lead them through
B first, if that's how the process flows.

A different entry process might smooth all these issues. What about
having your users enter their info in global fields...and then when
completed hit a "Submit" button that THEN creates a new record, setting
all the regular fields with the data in the globals. This setting script
can filter for incomplete or incorrect data in many ways (giving lovely
developer-determined user prompts along the way)...and no new record is
created until they hit that button...so no record has to be deleted if a
user is called away in the middle, or decides to quit, or has to go look
something up.  I'm a big fan of designing the database to suit how the
users work...not making the users work to my design.

There are many ways to skin a cat, grasshopper. ;)

--

Allen & Allen Semiotics                          Web & Graphic Design
Long Beach CA USA               Filemaker Pro Consulting - Member CSA
562.938.7890  fax 562.938.7891            Custom Solutions & Training

|You need a little more thought in your user-interface issues. Why are
|users having to look up info they can't access from file A to complete a
|new record?  Bad design.
Because the user is actually doing two different things at once.  In
File A, they are adding new people to the database. In File B they are
recording purchases the people have made.

If I'm sitting at a blank 'Add New User' screen and some one comes up
with purchases, I want to jump to the 'Record purchases' screen.  I
can't because Filemaker see the blank 'Add New User' record as
incomplete.

|A different entry process might smooth all these issues. What about
|having your users enter their info in global fields...and then when
|completed hit a "Submit" button that THEN creates a new record, setting
|all the regular fields with the data in the globals. This setting script
|can filter for incomplete or incorrect data in many ways (giving lovely
|developer-determined user prompts along the way)...and no new record is
|created until they hit that button...so no record has to be deleted if a
|user is called away in the middle, or decides to quit, or has to go look
|something up.  I'm a big fan of designing the database to suit how the
|users work...not making the users work to my design.

Now I'm getting the picture....    

Will I be able to leave the incomplete global entries and make an entry
in amother file?

|
|> I have this relational database that the user jump around in.
|>
|> Let's say the user is sitting at a new record screen on file A, but they
|> need to jump to another screen and look up another record on file B.
|>
|> Filemaker won't let them jump until the new record is filled out
|> completely. So I let the user delete the blank record and they go on
|> their merry way.  
|>
|> This creates a problem in that they can also delete a previously created
|> and complete record.
|>
|>
|> The solution, If I knew how, would be;
|>
|> If this record has a value in field 'X' it is not delete-able except by
|> a supervisor.
|>
|> OR;
|>
|> a person with this password can only delete empty records.
|>
|>
|> HELP!!!  I have smart-ass users deleting records!  But if I restrict
|> them, they cannot jump from one screen to another with completing the
|> first screen. :(
|
|You need a little more thought in your user-interface issues. Why are
|users having to look up info they can't access from file A to complete a
|new record?  Bad design.
|

|
|There are many ways to skin a cat, grasshopper. ;)
|

Apparently because you are using validations (like "not empty") within the
field definitions.  They seem to be so convenient, but now you know why a
some developers don't use them that often.  Too restrictive.  Replace them
with a script that checks data before allowing your users to continue (in
File A).  That way they can switch to File B at any time without being
stopped by incomplete records.

: |You need a little more thought in your user-interface issues. Why are
: |users having to look up info they can't access from file A to complete a
: |new record?  Bad design.
: Because the user is actually doing two different things at once.  In
: File A, they are adding new people to the database. In File B they are
: recording purchases the people have made.
:
: If I'm sitting at a blank 'Add New User' screen and some one comes up
: with purchases, I want to jump to the 'Record purchases' screen.  I
: can't because Filemaker see the blank 'Add New User' record as
: incomplete.
:
:
: |A different entry process might smooth all these issues. What about
: |having your users enter their info in global fields...and then when
: |completed hit a "Submit" button that THEN creates a new record, setting
: |all the regular fields with the data in the globals. This setting script
: |can filter for incomplete or incorrect data in many ways (giving lovely
: |developer-determined user prompts along the way)...and no new record is
: |created until they hit that button...so no record has to be deleted if a
: |user is called away in the middle, or decides to quit, or has to go look
: |something up.  I'm a big fan of designing the database to suit how the
: |users work...not making the users work to my design.
:
: Now I'm getting the picture....    
:
: Will I be able to leave the incomplete global entries and make an entry
: in amother file?
:
:



: |
: |> I have this relational database that the user jump around in.
: |>
: |> Let's say the user is sitting at a new record screen on file A, but
they
: |> need to jump to another screen and look up another record on file B.
: |>
: |> Filemaker won't let them jump until the new record is filled out
: |> completely. So I let the user delete the blank record and they go on
: |> their merry way.  
: |>
: |> This creates a problem in that they can also delete a previously
created
: |> and complete record.
: |>
: |>
: |> The solution, If I knew how, would be;
: |>
: |> If this record has a value in field 'X' it is not delete-able except
by
: |> a supervisor.
: |>
: |> OR;
: |>
: |> a person with this password can only delete empty records.
: |>
: |>
: |> HELP!!!  I have smart-ass users deleting records!  But if I restrict
: |> them, they cannot jump from one screen to another with completing the
: |> first screen. :(
: |
: |You need a little more thought in your user-interface issues. Why are
: |users having to look up info they can't access from file A to complete a
: |new record?  Bad design.
: |
:
: |
: |There are many ways to skin a cat, grasshopper. ;)
: |
: