How can you use in a script to go to record via a record ID.

It looks like the go to record script wants to use record number, but for my script this is not the best solution since it's based of the # records shown.

Thanks

Devin

Hi Devin,

Go To Record/Request/Page does indeed want a record number - it moves the focus forward or backward through your record set. And a RecordID is always unique to each record in a table.

It sounds like what you want is to jump to related records based upon a unique KEY field. Can you describe what you're trying to do? Do you have a one-to-many relationship now?

If so and you have established a proper relationship in the graph (and you are on a layout based upon the ONE-side table (for instance Customer) and you want a found set of that Customer's Invoices (the MANY side), you evoke GTRR - Go To Related Records [ Show Only Related ].

You can also perform a regular find. But we just don't have enough to go on here.

LaRetta

Devin, I read back through your posts to try and get a feel for your structure so I could make informed suggestions. I think I have one.

Create a second table occurrence of Jobs.

Join JobID > JobID

You will be provided with a portal (in which you can place ALL your job fields from those previous jobs). Sound familiar, Michael?

Maybe I'm wrong, Devin, but each of your posts indicates you are bumping into this same problem. You were presented with a perfect demo from Michael (comment) and were also assisted by Mike (Ender) and SlimJim. Did you even try applying the demo theory in your tables? Why do you feel you need to reserialize those IDs? What do you have against Auto-Enter? What went wrong in your implementation of their suggestions? It appears to be the perfect solution in my book.

LaRetta

Well the autoenter worked great, but it would only show me just the job #, what I want to show other fields that belong to those records and be-able to go to that record.

When I get to work I will put up my working file so you can get a much better idea on what I'm trying. I've had a few local users here look at my same problem and were stumped. It's quite hard to understand due to the way I ask it i guess.

I'm there now but I see a big problem with record # and not ID.

Thanks

Devin

OK here is my proof of concept file.

The script That I'm using now is Look up Previous job.

This should give you a better idea on what I want.

Thanks.

Devin

Ticket.zip

Devin, I'm sorry. But I have no idea why you have the multiple job_numbers. You don't need them at all. Before your solution becomes even more convoluted, I suggest you back up ... clear your mind of everything ... grab comment's demo and give it another try. If you keep moving down this path, things will only get harder for you.

Your job_number_previous_list text field will simply NOT update ... it's based upon a different TO. That is just one example, of course. Your 'Look up Previous Job' script wouldn't even be needed if the relationship were correct. Your process is totally illogical to me, so I can't even make suggestions.

You will end up horsing this entire solution via script and you'll be cursing FileMaker because ... way back when ... you were given the answer which you simply didn't see.

LaRetta

Comments demo is saying every job is related to the previous one. I don't need that all. not every job has a previous job.

Since this is my proof of concept database there are a few things in there that I don't use, Like job_number_previous_list. It was a try based off of another thread, but I was only able to get the job #, I need to see other items that belong to that record and be able to go to that record like it's a portal.

I don't know how else to do it, let alone getting someone to userstand what I want, I do know what I want, but going about it has become hard.

Maybe I should make a much simpler file to show what I want, and I do thank you for trying to help.

Thanks

Devin

Devin, I'm sorry. But I have no idea why you have the multiple job_numbers. You don't need them at all. Before your solution becomes even more convoluted, I suggest you back up ... clear your mind of everything ... grab comment's demo and give it another try. If you keep moving down this path, things will only get harder for you.

Your job_number_previous_list text field will simply NOT update ... it's based upon a different TO. That is just one example, of course. Your 'Look up Previous Job' script wouldn't even be needed if the relationship were correct. Your process is totally illogical to me, so I can't even make suggestions.

You will end up horsing this entire solution via script and you'll be cursing FileMaker because ... way back when ... you were given the answer which you simply didn't see.

LaRetta

I think a base demo is a good idea. I'm in the middle of a project but I'll certainly try to help if I can find the time, Devin. However, there are many wonderful people here that would also help, I'm sure.

I'm not very good at relationships, calculations or scripts but - other than that - I'm an expert in FileMaker. ROFLMFAO!!

OK...I will try and get a base file out and again thanks for your ideas.

Devin