Confused!!!!!

[jjosh12]

copying a record to another data file

#63960 - 04/18/03 12:39 AM Edit Reply Quote Quick Reply

I have created 2 different data files:

<***> = a button to edit field

(***) = the field

heres what they look like:

#1

COMPLAINT FORM

<Complaint#> (5477)

<Date> (4/12/03)

<customer#> (131316)

<customer name> (John Doe Co.)

<address> (576 East Ave.)

<complaint> (discription)

<date recieved> (4/11/03)

<send Info to new investigation form>

#2

INVESTIGATION FORM

<inestigation results> (type in details)

<date> (date)

<performed By> (john doe)

<close investigation>

And here is what I want to do:

I want to be able to fill out the first form, and when Im done push the <send info to investigation form> button and it runs a script that will copy the entire currtent record with the buttons and the field info exactly the way it appears in the complaint form and paste it in the top portion of the investigation form in a new Investigation form record. (minus the <send info to investigation> button)

In the new investigation report form record:

-I do not want modification to be allowed to any of what was copied and pasted from the complaint form record.

-Want to only allow users with permission to access the new record and fill in the investigation information.

-delete original complaint information record.

the result looking like this after the the complaint form <send info to invest.> button is pushed:

COMPLAINT FORM

<Complaint#> (5477)

<Date> (4/12/03)

<customer#> (131316)

<customer name> (John Doe Co.)

<address> (576 East Ave.)

<complaint> (discription)

<date recieved> (4/11/03)

<send Info to new investigation form>

INVESTIGATION FORM

<inestigation results> (type in details)

<date> (date)

<performed By> (john doe)

<close investigation>

Is this possible and if so can someone tell me how in a decient amount of detail. My brain is about to pop trying to figure this out. Would a script be the best way to do this.

also : there are no relationships defined or anthing else other than the fields and buttons being defined. I just have the visual look made and the format of each file made up.

Should I define any relationships if so which ones and how.

Any information would be greatly appreciated.

thank you in advance

Josh

[Fitch]

My first question is: why do you want to copy all the data to another file? Why not just use different layouts? Also, what do you mean by "a button to edit field"? Why do you need a button to edit a field?

My best guess without more info is that you want a data entry screen with global fields to enter the data. A script attached to your "send Info" button would then create a new record and move all the global data to standard field, e.g., Set Field[Date, globalDate]. Then it would clear out the global fields, and take you back to the entry form, or to some other layout of your choice, e.g. the investigation report.

There are various ways to control access to fields, records, and/or layouts. A very easy way to prevent field modification is, on the investigation report layout, select the fields that you don't want changed and go to Field Format, and uncheck the "allow entry into field" checkbox.

As for controlling access to the layout or record, you'll want to set up passwords and groups and go from there.

[jjosh12]

What I am doing is making a database to handle customer complaints. The complaints are handled in steps, i.e., Customer Complaint Form->Investigation Form->Conclusion...etc., and each step is handled at a different time.

In each step of the process the next form to fill out is to have only a specific group handle that specific form. In each new form I want the user who is entering the current information to be able to view all the forms leading up to this one but not be able to modify it.

I want to use a button that when pushed will run this script I recieved from Ugo:

File A

script A-1:

Set error capture (on)

Allow user Abort (off)

Show all records

Omit record

Show Omitted

------

File B

manually prepair an import of the fields in File B to import

------

File B

script B-1:

Go to record (last)

Import record (file A, No Dialog)

------

File A

script A-2:

Delete record

Show All records

------

So the structure is:

Script A-1

Perform External script (File B, Script :

Script A-2

I assign this script to the Button because once A form is filled out it is only important to the next level of the complaint handeling process. So I dont need a record to later look through at this level of the procedure.

So if a record does exist in the database and It is the File Form a specific user or group is in charge of handling, they open it up and it is automatically assigned to them until the form is complete and ready to proceed to the next form of the customer complaint handling procedure. This is when the user pushes the <button> and the information in this record gets inserted into the next Step of the handeling procedure and is no longer a record in their targeted section of the procedure.

here is a brief diagram:

<complaint form>_all users

COMPLAINT

-

<investigation form>_group1

COMPLAINT (UNMODIFIABLE)

INVESTIGATION

-

<results form>_group2

COMPLAINT (UNMODIFIABLE)

INVESTIGATION (UNMODIFIABLE)

RESULTS

-

<end complaint form>_group3

COMPLAINT (UNMODIFIABLE)

INVESTIGATION (UNMODIFIABLE)

RESULTS (UNMODIFIABLE)

END COMPLAINT

-

<archive form>_group4

COMPLAINT (UNMODIFIABLE)

INVESTIGATION (UNMODIFIABLE)

RESULTS (UNMODIFIABLE)

END COMPLAINT (UNMODIFIABLE)

ARCHIVE TO STORAGE

-

ARCHIVE IN STORAGE (UNMODIFIABLE)

am I going in the right direction. I appreciate any input.

thanks

Josh

[Ugo DI LUCA]

Hi Josh,

The more you give us details, the more I think that you're missing a very important point : FM is a relational database.

First of all, forget about my script as I should have asked (as Tom) why you wanted this script for.

Second, take some distance and you'll notice that the whole solution you're currently designing is not that different from any "business" solution where you would have these steps :

Proposal ----> Order -----> Invoice.

For sure, we wouldn't like to change a proposal when it has been invoiced, nor a customer order. Neither would you like your form to be altered when processed.

The whole thing is based on a Line Item, where each step is a key and with multiple relationships to the Customer_Id.

A unique Id for any complaint would be stored in this line item to handle the whole history of that complaint, but each step would be stored in different databases.

You'll set the "allow modification" either by calculation (a selfjoin on Unique Id and a calculation is not Empty (next step) could do the job to find if the form has been passed to the next step) or by Access Privileges.

If you want certain users to browse only the case "actives", then you'll need ceratin calculation and surely different layouts according to their privileges.

But there is no need to pass the information by script having a structure where :

file A = 5 fields

File B = 12 fields + the 5 fields from File A

File C = 10 fields + the 17 fields from file B.

This is definitely not good design IMHO.

Tell us what you think and if you didn't understood.

[Fitch]

Yep, this really looks to me like you should make each of your "forms" correspond to a FileMaker layout. Also note that you can make separate layouts for data entry vs. printing. To control access, make one or more "status" fields so that you can send the user to to proper layout for that particular record/complaint at each stage of the process.

I highly recommend that you familiarize yourself with the various access privileges, so you can get an idea of the possibilities.

[jjosh12]

Fitch

I think I understand what you are saying. Are you saying that instead of using a different template for each "form" I should use just use one template and use a different layout for each form?

I don't quite understand what you mean by "status" fields. Would you mind going into more detail on these.

My big delema I am having is that I need to make the whole user process easy enough for a 10 year old (a 10 year old of yesteryear not of todays auto-computer adaptive kids). The users that are going to use this do not know how to use computers for the most part at all, not even the normal amount of being able to use e-mail. I want to make sure that there is no way that the users can color outside the lines. I am even worried about them being able to use any search functions without getting confused, until they get familiar with the program. This is why I want to throw away any past records after they are imported. I am not exagerating when I say that the users only know how to use paper forms to fill out information. The company would rather spend money on developing a idiot proof data entry process than anything on training of how to use filemaker. I also am a "Newbie" with Filemaker and am not exactly sure how to accomplish this in my head without getting dizzy.

Any suggestions?

(other than hiring someone, this is out of the question for the company for security reasons, and I am the only one from within technologically qualified)

thank you for your input and patients

Josh

[jjosh12]

Ugo,

Im don't fully understand about "line" items.

If in each form template I create relationships with a unique complaint ID# when a ID# that is already in circulation is put into this field will it automatically fill out all the other fields that are redundant thruout all of the previously filled in forms?

Or am I completely lost (like I feel)

Josh

[Fitch]

1. As to your question about line items, the answer is yes, the fields will automatically fill in if you set their Lookup values in Define Fields.

However, I'll say again, I just don't see why you'd want to do that:

2. "Are you saying ...I should use just use one template and use a different layout for each form?" -- yes.

3. "status" fields

I'm using this term in the conventional sense, just a standard text field (I'm calling it "Status" but you can call it whatever you like) that you set to COMPLAINT, INVESTIGATION, RESULTS, END, or ARCHIVE. Then you use a script like:

If [status = "RESULTS"]

.. Go to layout [RESULTS]

End If

etc.

So if you take the user to a layout when they start up that has a field to search for i.d. and/or name, then does a Find and goes to the appropriate layout based on the Status field, you're most of the way there.

4. If you're worried about users getting confused and/or screwing things up, you'll need to tightly control access and script all your navigation etc. In the Find described above, for example, I'd use global fields on the startup layout and a script that sets the globals into searchable fields.

This isn't exactly newbie stuff. OTOH it ain't rocket science. Get yourself a book, download samples of others' work <http://www.fmfiles.com/tnt3.html> that you can study, and drink lots of coffee.