Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 6739 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted (edited)

I am attaching a copy of my script for any help suggestions anyone may have.

First problem: Every few runs the script crashes FM and I must restart it. I have not had more than 50 records in the queue at any time. It has happened with as few a 4 records.

Second problem: As you will note I am creating a history log after each email is sent. To send 36 emails took about 6 minutes. I am assuming it is the create record portion that is slowing down the process. Is there a way to send the emails first and create the records afterwards?

Third problem: The ::gMailSent counter drove me nuts. I finally have it working, but can't help but feel it could have been done better.

Overall the script is finally working and doing what I want, but, I'm sure there is a more elegant way to do it and because of the crashes I am afraid this script is a disaster waiting to happen. After one of the crashes I had to do a "Recover" to get the file back. Fortunately I make backups after I make any major changes so I was able to get my files back. The recover was not perfect.

Any help, suggestions are greatly appreciated.

Thanks,

Batch_email_script.pdf

Edited by Guest
Posted

- For starters you don't need a Go to Field step before a Set Field step. All you need is the Set Field step.

- Why is there no data associated with the Set Field steps under #Set fields for mailing? same for the Set Field[EmailActivity::geMail Status] under #Send Mail.

- The last line of your script is an End Loop step... where is the (begin) Loop step.

Posted

The last line of your script is an End Loop step... where is the (begin) Loop step.

Whoops, left that part of the script out. Please see new pdf below.

For starters you don't need a Go to Field step before a Set Field step. All you need is the Set Field step.

Whenever I use a Set Field without the go to field step I do not get the intended result. So I starting using the go to step and have had no problem. Maybe I'm doing something wrong and you can see it in my script, but, without it the data does not go into the proper field for me. I tried on several different scripts with the same results so I'm using what works for me. I would love to be able to do away with the extra steps.

Why is there no data associated with the Set Field steps under #Set fields for mailing? same for the Set Field[EmailActivity::geMail Status] under #Send Mail.

I originally got the makings of this script by reviewing other scripts on this forum as well as the scripts supplied by SMTPit. This is how they set it up, so this is how I set it up. I get all the proper data into the email and my emails reach their intended recipients. These fields are called for use in the SMTPit set field statements, i believe. I thought that when you used the Set Field statement alone it gathered the data in that field to be used when called upon from another set field command?

As I said I'm opened to any and all constructive criticism.

Thanks,

Al

Batch_email_script.pdf

Posted

Whenever I use a Set Field without the go to field step I do not get the intended result.

It seems you are not using the 'Specify target field' option in the Set Field[] script step?

Posted (edited)

I took a chance (I was raised in Queens, NY. : ) and deleted the go to field steps and low and behold it worked! I have no idea why it didn't work previously, but any time I can make something work with less steps it is a plus. Thanks for the suggestion.

But, the real problem is the script keeps causing crashes. This, to me, is a very large problem. Can anyone give me any idea what the problem may be? Is there something in the script? The order in which I am processing the commands?

My latest issue was I was getting an error message from SMTPit (I sent it in to their customer support team) and then the system crashed.

Also, when I go to shut down, after running the script, by X-ing out I get a different search that populates the layout. I then try to X out and the Mass eMail search comes up again. Then I can X out. But, I got an error message saying the FM program did not shut down properly.

Does anyone have any ideas?

H E L P !

Thanks,

Al

Edited by Guest
Posted

It seems you are not using the 'Specify target field' option in the Set Field[] script step?

I have a lot of Set Field steps in the script, some with the target specified, some without. First, it is my belief (And I know I may be all wrong), that with SMTPit you use the set field command to gather the data for later use when you use it to send mail.

Since the SMTPit commands can not be easily viewed I have attached a new pdf showing just one line of set field with SMTPit.

Thanks for your input.

Al

Batch_email_script_2.pdf

Posted

I don't know what a plugin has to do with this. Set Field[] changes the content of a Filemaker field. If the target field is not specified, Set Field[] operates on the currently active field. If no field is active, Set Field[] does nothing.

Posted

Im fairly sure there used to be a problem in advanced where set field didn't work correctly if it wasn't in the tab order or not allowed entry in browse mode or something before it got updated.

Posted

I don't know what a plugin has to do with this. Set Field[] changes the content of a Filemaker field. If the target field is not specified, Set Field[] operates on the currently active field. If no field is active, Set Field[] does nothing.

Not to be disrespectful because I really appreciate all the help I get from you and all the others on the forum, but, I don't know either. That's why I am asking the question. I'm only working with FM for 6 or 7 months and what I have learned is from this forum and ISO magazine subscription.

Somewhere I found a script that used the set field commands the way I have then laid out (or I thought that's the way it was) and since the script worked I kept using it in other scripts.

So, are you saying I can delete ALL the Set Field commands that do not contain a "specify target field?"

Also, are you saying that may be the cause of my crashes?

Additionally, is what Genx is saying correct? If so, can that be the cause of the crash?

Going back to my original question:

First problem: Every few runs the script crashes FM and I must restart it. I have not had more than 50 records in the queue at any time. It has happened with as few a 4 records.

Overall the script is finally working and doing what I want, but, I'm sure there is a more elegant way to do it and because of the crashes I am afraid this script is a disaster waiting to happen. After one of the crashes I had to do a "Recover" to get the file back. Fortunately I make backups after I make any major changes so I was able to get my files back. The recover was not perfect.

Any help, suggestions are greatly appreciated.

Thanks again,

Al

Posted

So, are you saying I can delete ALL the Set Field commands that do not contain a "specify target field?"

Not exactly. I am saying that unless there's a good reason not to, Set Field[] should contain BOTH the target field and the calculated result. Otherwise, you'd really need to go to the target field first, which (1) adds an unnecessary step and (2) requires the target field to be on the current layout (and in the correct context, I should add).

I have no idea what causes your script to crash, and no way of knowing. It's far beyond my skills to analyze such a long script, certainly when presented out of any context - not to mention that you haven't even told us the actual purpose of the script.

I'd suggest you divide the script into smaller parts, and check how well each part does in isolation.

This topic is 6739 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.