find and paste into mutilpe reords

[transit]

I want to be able to do a find which will bring up either one or many records and be able to paste information into a field in the found set in one go rather than having to paste the same information into each record.

Is this possible and any help would be appreciated.

many thanks

[Charles Delfs]

You can use a replace with calculation cript step in place of looping through all the records.

If the info can be looked up you can do a relookup also.

Charles

[transit]

I am not sure I understand your answer or maybe I wasnt clear with my question.

I have a db that has bills to pay. At the end of the month when the bills are paid i need to be able to add to the recordsthe cheque number and the date paid into the db against the invoices paid. So when i find 20 invoices that i have paid at the end of the month I want to be able to put the paid date in all of these records in one go rather than having to enter it in individually.

I hope this makes my question clearer

many thanks

[John Caballero]

If the check #s are different, there may not be any way around having to enter them on a per-record basis.

If the paid date is the same, though, Charles' suggestion still stands:

create a script that utilizes the Replace function.

[LaRetta]

Hi Transit,

If you can sort your found set of bills due (I assume those without a DatePaid or some other flag) in the exact sequence in which you write your checks - or even better, pay your checks in the natural order that your billing records are created (from a list for instance), then the answer is 'yes' you can set them with the check number and date paid.

Here is a suggestion on how you could accomplish it: Create a global (number) called gCheck#. Create a global (date) called gDatePaid and place them on a form layout (Find Bills Due). Include a button which will run your 'Find Bills Due' script below.

Create a Columnar layout called 'Pay Bills' and place your real Check#, DatePaid, Payee, Check Amount etc. in the body. Also, Insert > Button and place a button on the first row. Right-click it and Specify Button 'Omit Record.' In essence, your User will enter the beginning Check# and DatePaid in the globals, find all unpaid bills, switch to a list, omit any bills that should be skipped (shame on you, smile) and then run the second script (Pay Bills) by clicking a button in the header. Place another button on the first row with the third script 'Pay Just This Bill.' As with most (all?) scripts, I would include the usual two opening steps - Allow User Abort [Off] and Set Error Capture [On].

First, manually perform your find for unpaid bills (blank Check#, for instance). Then attach this script to your button by your globals:

Find Bills Due script:

If [isEmpty(gCheck#) or IsEmpty[gDatePaid]

Show Message [OK, "Check # and Date Paid must both contain data."

Exit Script

End If

Perform Find [Restore, Replace Found Set]

If [not Status(CurrentFoundCount)]

Show Message [OK, "No bills due. "]

Show All Records

Exit Script

End If

Go To Layout [bills Due]

Place a button in the header of your Bills Due list and attach this:

Pay Bills script:

Go to Record/Request/Page [First]

Set Field [Check#, gCheck#]

Set Field [DatePaid, gDatePaid]

Set Field [gCheck#, gCheck# + 1]

Loop

Go To Record/Request/Page [Next, Exit if Last]

Set Field [Check#, gCheck#]

Set Field [DatePaid, gDatePaid]

Set Field [gCheck#, gCheck# + 1]

End Loop

Set Field [gDatePaid, DateToText["")

Then, attach this script to the 'Pay Just This Bill' button in the list body:

Pay Just This Bill script:

Set Field [Check#, gCheck#]

Set Field [DatePaid, Case(IsEmpty(gDatePaid), Status(CurrentDate), gDatePaid)]

Set Field [gCheck#, gCheck# + 1]

Show Message [OK, "This record will now be omitted from the bills to pay."

Omit Record

In this way, your check numbers will start where they left off last time but your User will be required to insert a gDatePaid if paying more than one record. And omitting a check if it's manually paid should eliminate the potential problem of then running the Pay Bills script and overwriting the already assigned Check#.

A few things to keep in mind: 1) If you have a printer problem and mess up a check or start a new check-number sequence, you may have to manually correct one check-pay cycle. But, since Set Field replaces the entire contents, you can re-run the series if need be by just re-setting the gCheck# and gDatePaid and re-executing the script. 2) You might consider writing this final 'found set' to a global multiline for easy retrieval if you need to re-run it. Otherwise, just do a manual find on the DatePaid date. If you want to retrieve the check batch in this way, let me know and I'll help you adjust it. 3) If your checks also include alpha characters, Set Field will 'lose' the alpha. If this is the case, you will need to include a gCounter global (number) to count for you. If you'd like a description of this process, let me know.

Something interesting about Replace Contents I just learned on another Forum is that, if used in multi-user mode, Replace Contents does not return an error code if the record happens to be locked (thanks Ray). And there is no ready means to discover which records were updated and which were not because of this. At least Set Field will produce an error and allow follow up. It may not apply in this particular instance because you can scan the check set when done but, for this reason alone, I don't plan to use Replace Contents in multi-user environments.

LaRetta

[ESpringer]

Perhaps you want a *really* simple answer, so I'll fill in that end of the spectrum. If you have a found set with exactly the relevant records, the DATE part can be filled in all at once with no hocus pocus:

After you type the date into just one of the found records, hit Cmd = (on a Mac) or Ctrl = (I think that's right for a PC?) -- or choose "Replace Contents" under "Records" menu. Then when the dialogue box pops up, confirm that you want to put the value "12/04/2003" (or whatever) into this field for ALL of the found records.

Be CAREFUL with this, though, since if you accidentally do it with ALL records showing, you'll wipe out the existing data in those other records.

[LaRetta]

Hi ESpringer,

My reason for providing a solution is because it is possible to accomplish what Transit requested - set both the DatePaid and Check# at once - I've done it. My reason for mentioning potential problems associated with Replace Contents is that billing is important, and if a record happens to be locked, it will be missed which is really bad when working in any business/billing process. And, as you even said, Replace Contents can be extremely risky in the hands of a User without script protection of some sort, so I wouldn't suggest a manual check-paying process without it being scripted. Those two issues together suggest that a scripted method using Set Field is the safer choice, in my opinion. I would also include an error trapping procedure, but that's another story.

I believe one could 'post' or freeze record access (via a calculation flag) so Users can no longer access them (depending upon their Access Privileges), and then Replace Contents might work if it's scripted - knowing only the Biller has access to them. But why add another process just to protect from Replace Contents (for this one billing issue) when the entire solution will have scripted Error capture to isolate (and capture) those locked records for follow up? And why set the DatePaid manually and still be left having to hand-enter the check numbers when it could all be handled at once?

I appreciate the 'short answer.' My post may be long but it is far from complex. I tried to be concise but still explain everything needed. Transit hasn't been on forum very long and I don't know the level of his knowledge so I thought it better to explain more ... than less.

LaRetta

[transit]

A beautifully simple answer..... I like them

BUT yes I can see the problem of wiping existing data if you are not careful

On balance I may have to go with laRette for the fail safe option but thanks for the help

[transit]

Hi LaRetta

I thought last night I had solved this problem but after reading you message I realised I had left out so much.

I will try and have a go at this over the weekend

This will be used in multi user mode, so thanks to Ray and yourself.

[LaRetta]

Hi Transit,

One more thing I should mention...

In case you make a mistake in writing any of these scripts (particularly a script with loops), don't set Allow User Abort[Off] until after you are sure it works and you are ready to implement the process. If you end up missing a script-step or make an error anywhere, you could find yourself in a life-time loop - been there, done it (actually, more than once - including just last week)!

If you get into a perpetual loop, you can then [ESC] and get out of it. And remember to back up first, okay? Or better yet, play with this on a copy of your real db. Please don't be nervous hearing me say this however. I assure you the process outlined above will work for you, but I just don't want you to set it up on real data or real checks to begin with. I should be available through the weekend if you have any further questions about it or run into a snag. And have fun! I think you'll find, as I have, that FM is quite addictive.

LaRetta