which find method is better/easier

[skingjack2]

Hello,

I'm trying to determine which method is the optimum method of performing a find of client information. The setup is as follows: 2 databases (heavily based on the FM 8.0 integrated solution). 1 is for client info; the other is a booking database containing info on a travel booking (flights etc). The workflow is that the client first checks to see if the client is existing or new... the question is which of the following methods is best to perform this function:

1) from the booking DB, run a script that switches to the client DB and performs the find there and then copies the clients data (address etc.) back to the booking DB (assuming the client exists)- *I've seen this in an older FM integrated solution using a set field function but have been unable to duplicate) or

2)via a relationship(?), enter the persons last name in a field in the booking db & the information is pulled from the client database.

Hopefully you are not totally confused. FWIW, I'm eventually looking for this solution to somewhat mimic the Everywhere Travel examples that FM uses in their manuals.

Thanks to all that respond.

jack

[skingjack2]

Further to my original question, would it be best to

create a portal in the booking db with the associated related address fields (first name, last name etc) and then using the find function based on whatever field I choose i.e first name.

jack

[Søren Dyhr]

Well neither, but mostly 2) ...linking on the data such as name is vulnerable - due to typos.

What do you mean by:

pulled from the client database

Tunneled or Lookup, and if Looked up why??

--sd

[skingjack2]

Sorry,

Should be more specific about the terminology =)

By "pulled" I mean the data should be looked up from the client database and the requested data (i.e. address info) be placed into the booking database.

Why? Other than method 1... that's the only way I could figure to achieve the desired end result (and never heard of "tunneled" before in reference to FM. What is this?).

HTH.

Jack

[Søren Dyhr]

Lookups should be utilized with hessitation, only data of historic value should be "placed" by a lookup. Since the ideal of relatinal databases is to have each data in just one place so the maintance of it is simply done there.

This is pretty essential for the understanding of the way Filemaker is intended to work.

Let me give you an example. A persons address usually contains linked or dependant info, the postcode point uniquely at a town/city name - why should each tables content be burdened by several copies of that name, when all it takes is having the unique identifyer to tunnel the value in for visibility to the user on demand.

It's urgent that you understand the difference here, and it could perhaps be of benefit to you to watch this movie:

http://www.filemakermagazine.com/videos/graph-rules-four-rules-to-remember.html

--sd

[skingjack2]

:) Did it again... sorry,used wrong terminology... should not have used the term "lookup". In fact, it would definitely be a relationship

being used. My initial problem I'm encountering is my current flat file is inefficient & I'm having issues as to how to breakout the client info from the booking info. I've set up the relationships

based on client IDs; based on the previously mentioned workflow (basically, when creating a new booking, check to see if the customer exists or is new) I need to know how to do a find on the name to see if the customer exists & which database to do perform the find on (i.e. from a portal on the booking db related to the client db OR switch to clients db, perform the find and then transfer that information to the booking database).

Hopefully I'm not confusing you even more

Jack

P.S. Thanks for the link to the video-quite informative.

[Søren Dyhr]

When speaking of booking, could you use this approach, which isn't finding at all, but instead filtering a portal, from where the selection then is done from:

http://www.nightwing.com.au/FileMaker/demos7/demo705.html

--sd

[skingjack2]

Sd,

Thanks for the link; I reviewed the solution but

it is not the type of "booking" I had in mind (there is that terminology thing again). The context I use the term "booking" is in reference to a reservation one would make when traveling i.e. what a travel agency might need to keep track of abouts it's clients: destinations, flights, payment method etc. If you are so inclined, I can forward you clone of the current db so you can get better understanding of what I'm trying to achieve; this may save us considerable time/effort when I encounter future problems (which I guarantee will forthcoming - that's how I learn

...albeit slowly).

As always thanks for taking the time to assist.

Jack

P.S. if you you have any more suggestions on where

I can improve/learn more about FM tips & tricks, please let me know.

[Søren Dyhr]

If you can wait until thuesday/wednedsday (14th-15th)....I'm right in the middle in a crashtest of a filemaker developed logistics system for a rock-festival. Turn to my profile and send me your file ...if you still are interrested??

--sd

[skingjack2]

Hello Sd,

Hope the musical event went well; by that I mean it turned into a non-event from your perspective Yes, I'm still interested in your assistance...took some time off to attend to other items while you were busy. I'll be forwarding you a clone of the database in question

(actually 3) so you can see how I have everything messed up (be forewarned it's not pretty, literally and figuratively). In addition, I'll be sending a file which sort of outlines what I'm attempting to do (fyi, check my other posts in the

scripting section under "set field to temp data"; it'll provide you advance info on the issues I facing).

Jack

[skingjack2]

Hello Sd,

Check your email for the db files.

Jack