Configurator returning 4GL errors during order entry "Saving Configuration" step


Since last week Thursday we have been having issues with our configurators. At the beginning of the day when the database has been freshly restarted we are able to enter in orders with our configurators with no issues at all. Then at some point during the day during the “Saving Configuration” portion of the process the configurator times out with a 4GL error. From then on for the rest of the day no one can enter an order which uses a configurator. They all get the 4GL error. We have been searching all of our logs to find out what may be going on but have not been able to come up with the cause or a solution. We are on Epicor 9.05.700C 64-bit Progress database.

Thank you!

Hi Jill,

I would suggest checking the E9 AppServer log to find the details regarding the 4GL error. If you can find the server log entries, and send them back, that would be good.


Roger Bomford

Here is the appserver log entry where one of our Order Entry gals got a 4GL error when entering an order with a configurator.
It appears that if I stop the appservers, stop the database, stop the OpenEdge Admin service and then restart everything that they can enter orders for a couple of hours. Then after that the six Order Entry people start to get 4GL errors when “Saving Configuration” during order entry. Not sure exactly what is going on.

Hello Jill!

It looks like there’s a BPM running on your Configurator (SaveOrderConfiguration). Maybe there’s a clue in there?

Mark W.

Yes, it looks like it may be a BPM. I would first try disabling any method directives in the Configuration.SaveOrderConfiguration BO/Method.


Thanks Mark and Roger!!!
That gives us something to look at. Any reason why this BPM would all of a sudden go haywire? Just wondering if you had ever experienced anything like this.

Thanks:>) You guys are the best!

Hard to tell without looking at it. Maybe it’s logging to a folder and the disc is getting full? Or whatever it’s doing has a memory leak so you’re running out of stack/heap? You may find it’s only needed to debug the configurator and you can safely disable it.

This is very interesting - we can enter an order using a configurator into quote entry with no problems even when our Order Entry with configurators us gummed up. It is only in Order Entry that we are experiencing the 4GL errors when trying to use configurators. After a clean reboot of our database server our Customer Service Team can enter orders using configurators for 45+ minutes before they start to spin and get the 4GL errors. Any ideas?

Were you able to get to BAM and see the code behind the BPM that’s blowing up?

We fixed the one BPM that you told us about. Did not make a difference. Order Entry still locked up after a clean reboot and being able to enter orders with configurators for only about 45 minutes.

Right now we have a Source Day web page turned off since 3:30 p.m., did a clear reboot at 3:30 p.m. and order entry with configurators is still going strong. Order Entry is going home at 5:30 p.m. so will try this test again tomorrow morning.

Just wish we could find the smoking gun:>( Very frustrating!!!

We figured out our issue!! We have Source Day running on our Epicor LIVE server. Source Day uses a SQL Express database and Epicor is using Progress. The SQL processes and the saving of our configurators were both fighting for resources on our server and Progress was losing. Yesterday we shut off the SQL database and have not had any issues since. We will be moving the Source Day SQL database of our LIVE server.
Thank you for all your time, tips, hints, expertise, etc. It was really appreciated.

Have a wonderful weekend!


1 Like

Fantastic, Jill, glad you got it sorted out…!


We had some more investigation and found out by using the DBTools against our Progress database that a comment field on a line on one of our Purchase Orders had 2650 characters in it and when you are using ODBC to pull the Progress data over to a SQL database the SQL cut that field off at 2000 characters. So every time Source Day was trying to do a pull against our Progress database it would get hung up on this one field on just one Purchase Order and spin and spin and spin. We have since deleted the Purchase Order (because we no longer needed it) and now everything is back to normal.

Since learning all of this we are now asking Source Day to just pull over the data that is associated with the vendors that are signed up to show on Source Day and not all the other miscellaneous purchase orders. This will make the amount of data being transferred at any one time a lot less and it is more likely that a big comment field will be on a miscellaneous purchase order than a regular purchase order. Lots of headaches, stress, reboots of Epicor just to find out that a comment field was too large. Grrrrr!!! Was a good learning experience though:>)


Jill Schoedel