My Findings....

[macmangler]

I am reposting my topic from a day ago. I received many great replies, I thank you all, but after hours of playing with your feedback and googling the internet... I am still stuck, and consider my solution may be the best one going.

My dilemna (in this simple example), I have 2 databases, contacts and jobs. If I am in my contact database and opt to generate a new job ticket, I want a script to simply take me to my job database, make a new record, and auto input the contact info I was reviewing at the time I started the script (My active contact record).

It was suggested to use portals. I played with portals, but they are based on individual fields, not calculations. My Job ticket exposes my client contact info as a calculation. So I ruled this out.

It was suggested to use "setfield" script. Great script, but does not work from one database to another, while making a new record. The script "setfield" dies as soon as a new record is generated in the same script. I also found a post... Post#199015 Using Set Field.... with attached download. Again the script works, but nowhere does the script contain a "new record." When I add the step into the script, the script goes dead. So I ruled that out.

I did learn about multiple tables inside one database, thanks to one post. I am considering converting to this. The one advantage between having one database verses having multiple databases is scripts. When you jump from one databse to another, you essentially need to open another file and perfom a script on that databse, thus you need 2 scripts always. Twice the work. Other than that, separate files or multiple tables... relationship are equally easy. I think this part is preference. However, I still think one database with multiple tables, verses multiple databases is slower on the network. When you have multiple clients accessing one database... it does slow down. Independently, if one client is using invoicing, one updating clients, and one client making job tickets at the same time... I believe separate databases is faster on the network. That would be an interesting challenge to the FIlemaker Gods.

Oh... the only solution I came up with... was the copy and paste.

While in my Contact records, if I opt to generate a new job ticket with the active client information... a single script, copies my client ID... opens my job ticket database, creates a new record, pastes into a client ID lookup, thus creation a calculation of client inofrmation based on the ID relationship. My solution works both mac and pc (we're cross platform) and with web publishing... I eventually want to host this through Filemaker Server Advanced 8, so our second office can share jobs and contacts.

My only other thought for all your potential advice back, is that I make a simple file for you to look at.... find a better way. I started this post to begin with, because I thought copy/paste was a "primative" solution in FMP 6.... and still my solution in FM8... even stranger.

Thank you all for your time.... sorry for the long post.

[Genx]

Well, a couple of things, a) multiple files are quicker depending on how you split them, i.e. if you split data from GUI, other than that, the performance wouldn't really differ if you had 50 files with one table each or 1 file with 50 tables... unless your 50 files were on 50 different servers all with their own dedicated wireless bandwidth... i.e. the performance wouldn't really be affected (some may argue with me) - have a look at the seperation model on these forums for a better idea.

The second thing that comes to mind is this: simply combine the two files using a reference in a main file... this way you have access to all the data in the different files even if you did have 50 ... in your main file. To do this, go file--> define --> file references then you have full access to everything in that other file, including scripts which you can pass parameters to or simply the tables themselves so you can set your values directly from your main file.

Anyway, just read up, your one table files are going to give you a headache in fm8, they moved away from the whole thing for a reason... it was a pain (i mean no offence to those who still like and use fm6).

Anyway,

~Genx

[Søren Dyhr]

My Job ticket exposes my client contact info as a calculation. So I ruled this out.

Wrong decision, just becasue your filestructure is somewhat flatter than they ought to be, is it prejudice ...as simple as that.

Have you ever exposed the audience here to you what kind of tasks your fields performs, and why?? I suspect there are quite a deal of carry over from spreadsheets since portals are such a problem.

Could you if there are sensitive data, make a screencapture of your fields in the two tables in question? Or even better upload a clone??

--sd

[Tricky]

Mike: have just sent you email with some files attached. Let me know what you think! If it is useful information, feel free to share it.

[comment]

This is a public forum - feel free to share it yourself.

[Tricky]

OK, will do so tomorrow: the stuff is at work. However, it is in FMP6 because I do not have FM8 in production at work due to technical problems.

[comment]

The point is that no one has the vaguest idea what your suggestion might be - so in effect, you've brought this discussion to pause.

[Tricky]

Repeating a point does not make it stronger. It was already taken. I pledge to never do it again...

Just thought that my approach (in FMP6 at that) was not earthshaking to the general community hered. It might not even have been that to Mike. I asked him to let me know if it was helpful, as I am currently concentrating on writing Filemaker training material. That's all.

[Tricky]

As promised, here are the files that I sent to Mike. For those who have the same problem it might be helpful.

Contactfiles.zip

[Søren Dyhr]

My dilemna (in this simple example), I have 2 databases, contacts and jobs. If I am in my contact database and opt to generate a new job ticket, I want a script to simply take me to my job database, make a new record, and auto input the contact info I was reviewing at the time I started the script (My active contact record).

Maybe my question is a little daft, but it seems like a job consist of many jobtickets to make it up as a complete job?? Which structurally makes it similar to Client -< Invoice -

Not something you stumble over right away at a trial run or first encounters with fm7+, unless you are very strong-headed and knows relational approaches better than the majority of the participants in these forums, and eats recursive table structures for breakfast.

Let's instead focus on what a jobticket really is!

storing control information that isn't related to the content of the document and also a means of storing the job history.

This point's in two dimentions, the control information belongs perhaps to the job table as description, but the historic content is something added during the process, which makes it belong to another lineItem'ish kind of table, for storing issues like the time it has taken to get from a to b....

But before getting in too deep in guessing, must it be slightly clearer what the task is this system is supposed to perform, why are paperbased jobtickets not up to it. The answer could here be that for giving reliable quotes or estimates for future jobs, must a search be done to get an avarage price for both the time used as well as the raw materials similar jobs have pulled.

If we descripe the purpose like this, will we soon discover that every job could be split up in standard tickets discriping one single standardized task, this is way into the 4th table if that's what we're after?? Again does it bear strong resemblance to invoicing systems, now with 4 tables client -< invoices -< itemlines >-items ...here do we see that historic data ends up in itemlines, while the rest of the data is pulled or tunneled on demand and not stored in the layout which is our present POW.

--sd

[macmangler]

Hi....

OK... I am gonna attach (2) simple files for your review.

I want to look up my contact, when I find that "customer," I want to jump to my "job" database and automatically create a new record with my clients data already in place.

I put some notes in the files.

Thanks!

Mike

jobsncontacs.zip

[Søren Dyhr]

I have joined your two bases into a pair of tables in the same file, this makes it simpler if $variables were to be used, however is it pretty straight forward to make the button with a parameter. This will work as long the script is executed with a button, but if shortcut key combination are likely to be used, must a variable be loaded ...I've shown this in the 2nd script.

BTW are you not getting standing applauses and encore requests on your calculated field, mergefields or each of the individual values are a cleaner choise, since nothing except the ID is bought over. I think I can see what you're doing! It's the Address_2 thingy, where only some of you client require both! But it's not what we can see in the file?

As it is at present isn't it requirering a calcfield at all, it a fm6 bygone wher tunneling was done that way.

--sd

JOBTicket.zip

[macmangler]

Thanks... works perfectly!

I am somewhat confused as to why it worked and am disecting what you did...

Observations.... "optional script parameter"... this was set with the client ID #. I think this passed the text through?

And the "set field".... the target field is the the job id (makes sense), but the the calculated result is Get ( ScriptParameter ), this confuse me.

I appreciate your time and energy into this. With many databases, this solution will help jump around between databases much easier.

[Søren Dyhr]

Observations.... "optional script parameter"... this was set with the client ID #. I think this passed the text through?

Exactly! It's a storage place that exists during the time runs and picking this value for a purpose is done via Get(ScriptPar...

--sd

[macmangler]

Nice.... thanks for the help!!

Very appreciative!