Hi guys, it's that time where I think I am way over thinking something and so I have stopped to ask a question. Put simply I am working on a POS for a small business that may have up to 4 terminals in use at any one time. My question is this as layed out by the following scenario.

Terminal 1 and 2 and 3 are in use (for example). All terminals  are operating and putting customers stock through the checkout. Terminal 1 and 3 both perform a search for product through a search layout, both have results that need to be returned to the terminal and entered into the current sale they are respectively working on. How do I achieve this so they return to their respective records and not each others (if this makes sense). I have a persistant ID for all terminals and currently the result is a scripted return of the EAN (number) via copy into the relevant record on the terminal. ( Simple in it's theory and it works for a single user. I think there could be a far more elegant way of doing this) however, going back to my original question of the multi user scenario how would I make this work? Hope this makes sense.

I'm not sure that I am following.  If they are just searching for product; then it does not matter whether the same product is in someone else's found set if they were also searching for it?

My search result is never going to show up in someone else's found set.

Thanks Wim, Many a time you have helped me not necessarily directly but your comments help and as I said I thought I may have been way over thinking that part. So excuse my stupidity but returning to the terminal and last record each was working on would be achieved how? I dont think i can just use a go to last record as they potentially would end up on the same record. ( I think) again could be way over thinking. as there sales are stored in the same table just the terminal identifier determines which sale belongs to which terminal.Hope this makes sense. again excuse my stupidity but 20 cups of Java can do that to you.

 

I don't understand what you're asking either. Each user has their own found set (or more precisely, found sets), and their own current record in each found set. Users can end up on the same record - there should be no problem with that, as long as they don't try to modify it at the same time. I don't see why that would happen, if you set it up correctly - i.e. create a new record for each sale (and as many related records in line items as the number of items bought). There would be no reason for a conflict here.

Unrelated (?), but if you enter a unique identifier of a product, you should get the product's details through a relationship - not by performing a find and copying.

 

Edited March 24, 20169 yr by comment

Cheers comment, As I said I think i was way over thinking something. Just tiredness I guess it wasnt so much the find I guess but more the return to the correct record for that terminal with result as I was using another layout for the search results. However reading your reply the light came on ( I think?). Thats why sometimes Its good to step back when you are having a mental block or in my case way over thinking and ask a question to the people that are disassociated from the problem. Cheers and Thanks to both you and Wim. ( and yes I hate using copy and paste I steer clear of it for the most part it's just I couldnt think of another way forward)

18 minutes ago, Peter Barfield said:

it wasnt so much the find I guess but more the return to the correct record for that terminal with result as I was using another layout for the search results.

As I said, each found set has also its own current record. So even if you do go to another layout (i.e. another found set), you will be returned to the original record when you return to the original layout. As it happens, it's not necessary in your case (at least I don't think so). But in those cases where it is, you would use Set Variable[] and Set Field[] rather than copy and paste.

 

 

Edited March 24, 20169 yr by comment

Yep! got ya understand completely, Thanks for the help it really is appreciated.