A Bad Relationship

[Mark L]

(I

LetterProblem.zip

[LaRetta]

Hi Mark,

Two things ...

You can't use Auto-Enter (Replace) and have it work consistently when referencing through a relationship. I know I've seen people even here say to use it but it will not update properly. Auto-Enter (Replace) only functions properly when referencing fields from within its own record. If it did, we wouldn't need plugin event triggers.

And since Barney and Betty have the same PatientLetterID, your Letters table is only relating to the first one of them - or Barney. That's why Barney displays properly and Betty displays Barney's letter. You might try using a calculation (text) which would automatically be unstored because it's referencing a relationship and see if that helps; but I think that might defeat the purpose of what you're trying to do (upon quick review). Wish I had time to help you further on it but I'm on a deadlines now until late tomorrow evening. I'm sure others can help you through it.

LaRetta

[Mark L]

LaRetta-

Thanks for taking the time to look at this. I know you are busy - but when you get a chance, I'm still confused about the auto-Enter issue.

From my standpoint, I need users to be able to add their own records - in this case Letters. How would one do it without using an auto enter of some sort - base a key on some other factor?

At least I do understand what you said about issue with the same record appearing related to do different Patients. I think I need a way - which you hinted at - of regenerating the record for each patient. I'll keep thinking about that.

Much Thanks,

Mark

[Mark L]

LaRetta-

Thanks for taking the time to look at this. I know you are busy - but when you get a chance, I'm still confused about the auto-Enter issue.

From my standpoint, I need users to be able to add their own records - in this case Letters. How would one do it without using an auto enter of some sort - base a key on some other factor?

At least I do understand what you said about issue with the same record appearing related to do different Patients. I think I need a way - which you hinted at - of regenerating the record for each patient. I'll keep thinking about that.

Much Thanks,

Mark

[Mark L]

LaRetta-

Thanks for taking the time to look at this. I know you are busy - but when you get a chance, I'm still confused about the auto-Enter issue.

From my standpoint, I need users to be able to add their own records - in this case Letters. How would one do it without using an auto enter of some sort - base a key on some other factor?

At least I do understand what you said about issue with the same record appearing related to do different Patients. I think I need a way - which you hinted at - of regenerating the record for each patient. I'll keep thinking about that.

Much Thanks,

Mark

[dkemme]

If you want your users to be able to create new records in Letters, you need some mechanism to make sure that PatientID is set to the correct patient. First create a script, NewLetter, that goes to the letter layout, create new record, set field (PatientID, get ( scriptparameter )). If the user happens to be on the Patient layout when they decide to create a letter for that patient, simply create a button that calls the NewLetter script and passes PatientID as the parameter. If the user is shown a list of patients in a portal, create a button in that portal that passes the PatientID of that portal's relationship to NewLetter.

[dkemme]

If you want your users to be able to create new records in Letters, you need some mechanism to make sure that PatientID is set to the correct patient. First create a script, NewLetter, that goes to the letter layout, create new record, set field (PatientID, get ( scriptparameter )). If the user happens to be on the Patient layout when they decide to create a letter for that patient, simply create a button that calls the NewLetter script and passes PatientID as the parameter. If the user is shown a list of patients in a portal, create a button in that portal that passes the PatientID of that portal's relationship to NewLetter.

[dkemme]

If you want your users to be able to create new records in Letters, you need some mechanism to make sure that PatientID is set to the correct patient. First create a script, NewLetter, that goes to the letter layout, create new record, set field (PatientID, get ( scriptparameter )). If the user happens to be on the Patient layout when they decide to create a letter for that patient, simply create a button that calls the NewLetter script and passes PatientID as the parameter. If the user is shown a list of patients in a portal, create a button in that portal that passes the PatientID of that portal's relationship to NewLetter.

[Mark L]

Thanks Doug - I'll give it a shot and let you know what happens.

-Mark

[Mark L]

Thanks Doug - I'll give it a shot and let you know what happens.

-Mark

[Mark L]

Thanks Doug - I'll give it a shot and let you know what happens.

-Mark

[LaRetta]

Hi Mark,

Sorry I was too busy to respond in a timely fashion - network problems. Upon reviewing your file (which I

[LaRetta]

Hi Mark,

Sorry I was too busy to respond in a timely fashion - network problems. Upon reviewing your file (which I

[LaRetta]

Hi Mark,

Sorry I was too busy to respond in a timely fashion - network problems. Upon reviewing your file (which I

LetterSolution.zip

[Mark L]

Wow LaRetta, it's really late here, but I just took a moment to download your solution

[Mark L]

Wow LaRetta, it's really late here, but I just took a moment to download your solution

[Mark L]

Wow LaRetta, it's really late here, but I just took a moment to download your solution

[LaRetta]

Actually, after posting I realized you might want to bulk mail. I've attached a modified demo. You may wish to create a totally separate script but I incorporated it into the same script for simplicity. You could perform your find, then click the same button your Users would use to create one letter.

If the found set is less than the total set, the 'Create Letter' script assumes you wish to mail the letter selected to the found set. If all records are displayed, it assumes you just want to create a letter for the one person. Notice the Script Parameter attached to that button.

One more thing ... I hadn't added the ability to add multiple records, ie, if you try to send the same letter to the same Patient, the prior demo wouldn't allow it. Many times you won't want another duplicate Patient/Letter letter but sometimes you might. I meant to explain that so here's how to pull that off:

If you wish to use 'Allow Creation of Related' to generate a new record for you EVERY time you fire a script, just add a third key that will never match. In the attached example, I connected timestamps.

They will never match so the relationship will always create a new record when the script is fired. You can use a Case() calculation on the left side and set your own criteria, depending upon the LetterID (some letters will be a one-time thing); others may be annual, etc. to determine whether to fire the record creation.

LaRetta

Update, that's what happens when I'm too tired. I changed the demo - joining timestamps to create the unique third key.

[LaRetta]

Actually, after posting I realized you might want to bulk mail. I've attached a modified demo. You may wish to create a totally separate script but I incorporated it into the same script for simplicity. You could perform your find, then click the same button your Users would use to create one letter.

If the found set is less than the total set, the 'Create Letter' script assumes you wish to mail the letter selected to the found set. If all records are displayed, it assumes you just want to create a letter for the one person. Notice the Script Parameter attached to that button.

One more thing ... I hadn't added the ability to add multiple records, ie, if you try to send the same letter to the same Patient, the prior demo wouldn't allow it. Many times you won't want another duplicate Patient/Letter letter but sometimes you might. I meant to explain that so here's how to pull that off:

If you wish to use 'Allow Creation of Related' to generate a new record for you EVERY time you fire a script, just add a third key that will never match. In the attached example, I connected timestamps.

They will never match so the relationship will always create a new record when the script is fired. You can use a Case() calculation on the left side and set your own criteria, depending upon the LetterID (some letters will be a one-time thing); others may be annual, etc. to determine whether to fire the record creation.

LaRetta

Update, that's what happens when I'm too tired. I changed the demo - joining timestamps to create the unique third key.

[LaRetta]

Actually, after posting I realized you might want to bulk mail. I've attached a modified demo. You may wish to create a totally separate script but I incorporated it into the same script for simplicity. You could perform your find, then click the same button your Users would use to create one letter.

If the found set is less than the total set, the 'Create Letter' script assumes you wish to mail the letter selected to the found set. If all records are displayed, it assumes you just want to create a letter for the one person. Notice the Script Parameter attached to that button.

One more thing ... I hadn't added the ability to add multiple records, ie, if you try to send the same letter to the same Patient, the prior demo wouldn't allow it. Many times you won't want another duplicate Patient/Letter letter but sometimes you might. I meant to explain that so here's how to pull that off:

If you wish to use 'Allow Creation of Related' to generate a new record for you EVERY time you fire a script, just add a third key that will never match. In the attached example, I connected timestamps.

They will never match so the relationship will always create a new record when the script is fired. You can use a Case() calculation on the left side and set your own criteria, depending upon the LetterID (some letters will be a one-time thing); others may be annual, etc. to determine whether to fire the record creation.

LaRetta

Update, that's what happens when I'm too tired. I changed the demo - joining timestamps to create the unique third key.

BulkMail.zip

[Mark L]

LaRetta-

Thanks for developing "round two." I've studied the layout of things - and I think I understand the "disconneted" relationship using the timestamp. I see "bulk" letters "pooling" in the bulk letters file - cool.

This is making me think (out loud):

- I can simply create a radio button that will be - "Print Letter Now" or "Print in Batch." Then I'd work the "print now" option into your script. I also will need to delete the records after they print or at some point - or that file would have lots of dead wood over time. On the other hand - could I use GTRR to pull up recently sent letters either by letter (ID) or by Patient - and just clean out the file X days after a letter is printed?

- If they opt to print in batch - then before they leave the "letters" related layouts - I should ask "Print Bulk Letters Now?" - and then again before the whole application closes to warn/ask if they want to print letters before shutting down or else they will be left to print another time.

As usual, LaRetta, you keep both solving and sparking new ideas.

Thanks so much for all your dedicated work!

-Mark

[Mark L]

LaRetta-

Thanks for developing "round two." I've studied the layout of things - and I think I understand the "disconneted" relationship using the timestamp. I see "bulk" letters "pooling" in the bulk letters file - cool.

This is making me think (out loud):

- I can simply create a radio button that will be - "Print Letter Now" or "Print in Batch." Then I'd work the "print now" option into your script. I also will need to delete the records after they print or at some point - or that file would have lots of dead wood over time. On the other hand - could I use GTRR to pull up recently sent letters either by letter (ID) or by Patient - and just clean out the file X days after a letter is printed?

- If they opt to print in batch - then before they leave the "letters" related layouts - I should ask "Print Bulk Letters Now?" - and then again before the whole application closes to warn/ask if they want to print letters before shutting down or else they will be left to print another time.

As usual, LaRetta, you keep both solving and sparking new ideas.

Thanks so much for all your dedicated work!

-Mark

[Mark L]

LaRetta-

Thanks for developing "round two." I've studied the layout of things - and I think I understand the "disconneted" relationship using the timestamp. I see "bulk" letters "pooling" in the bulk letters file - cool.

This is making me think (out loud):

- I can simply create a radio button that will be - "Print Letter Now" or "Print in Batch." Then I'd work the "print now" option into your script. I also will need to delete the records after they print or at some point - or that file would have lots of dead wood over time. On the other hand - could I use GTRR to pull up recently sent letters either by letter (ID) or by Patient - and just clean out the file X days after a letter is printed?

- If they opt to print in batch - then before they leave the "letters" related layouts - I should ask "Print Bulk Letters Now?" - and then again before the whole application closes to warn/ask if they want to print letters before shutting down or else they will be left to print another time.

As usual, LaRetta, you keep both solving and sparking new ideas.

Thanks so much for all your dedicated work!

-Mark

[LaRetta]

Hi Mark,

It looks like you're on a roll now. Every solution is different and only you will know what works best for your business needs. I threw together several ideas which, taken as a whole, may not work the best. The point was to give you a glimpse of the power using relationships in FM7 and 'Allow Creation.' Many times I see Developers jumping all through their solutions to create new records when it really isn't necessary.

A few final thoughts ...

I also will need to delete the records after they print or at some point - or that file would have lots of dead wood over time.

Maybe. You may want a history of what was sent. If you wish to keep the file size down but maintain a history, you can Set Field [ Letters::LetterBody; "" ] at some point. This will greatly reduce the size but will retain LetterID, PatientID and PrintDate for reference.

... then before they leave the "letters" related layouts - I should ask "Print Bulk Letters Now?" ...

A suggestion message is nice - a requirement can be difficult to police. Trapping for all escape routes can be a bit tricky. But, if nothing else, you can certainly display a list of unprinted in a portal on your Main Menu; as a reminder of work left undone.

It is this variety of creative options that makes FileMaker so darned exciting. I will never get bored exploring possibilities and trying new things; and I refuse to get locked into a headset of, "Well, this is how I've always done it or this is how everyone else does it so I'll just keep doing it this way." I commend your enthusiasm and open spirit!

LaRetta

[LaRetta]

Hi Mark,

It looks like you're on a roll now. Every solution is different and only you will know what works best for your business needs. I threw together several ideas which, taken as a whole, may not work the best. The point was to give you a glimpse of the power using relationships in FM7 and 'Allow Creation.' Many times I see Developers jumping all through their solutions to create new records when it really isn't necessary.

A few final thoughts ...

I also will need to delete the records after they print or at some point - or that file would have lots of dead wood over time.

Maybe. You may want a history of what was sent. If you wish to keep the file size down but maintain a history, you can Set Field [ Letters::LetterBody; "" ] at some point. This will greatly reduce the size but will retain LetterID, PatientID and PrintDate for reference.

... then before they leave the "letters" related layouts - I should ask "Print Bulk Letters Now?" ...

A suggestion message is nice - a requirement can be difficult to police. Trapping for all escape routes can be a bit tricky. But, if nothing else, you can certainly display a list of unprinted in a portal on your Main Menu; as a reminder of work left undone.

It is this variety of creative options that makes FileMaker so darned exciting. I will never get bored exploring possibilities and trying new things; and I refuse to get locked into a headset of, "Well, this is how I've always done it or this is how everyone else does it so I'll just keep doing it this way." I commend your enthusiasm and open spirit!

LaRetta

[LaRetta]

Hi Mark,

It looks like you're on a roll now. Every solution is different and only you will know what works best for your business needs. I threw together several ideas which, taken as a whole, may not work the best. The point was to give you a glimpse of the power using relationships in FM7 and 'Allow Creation.' Many times I see Developers jumping all through their solutions to create new records when it really isn't necessary.

A few final thoughts ...

I also will need to delete the records after they print or at some point - or that file would have lots of dead wood over time.

Maybe. You may want a history of what was sent. If you wish to keep the file size down but maintain a history, you can Set Field [ Letters::LetterBody; "" ] at some point. This will greatly reduce the size but will retain LetterID, PatientID and PrintDate for reference.

... then before they leave the "letters" related layouts - I should ask "Print Bulk Letters Now?" ...

A suggestion message is nice - a requirement can be difficult to police. Trapping for all escape routes can be a bit tricky. But, if nothing else, you can certainly display a list of unprinted in a portal on your Main Menu; as a reminder of work left undone.

It is this variety of creative options that makes FileMaker so darned exciting. I will never get bored exploring possibilities and trying new things; and I refuse to get locked into a headset of, "Well, this is how I've always done it or this is how everyone else does it so I'll just keep doing it this way." I commend your enthusiasm and open spirit!

LaRetta