Sage 100

Beth, it seems that I have to do that more and more in the last couple of years (rename Links). I'm not sure why since that has never been a problem in past years.

Beth, it seems that I have to do that more and more in the last couple of years (rename Links). I'm not sure why since that has never been a problem in past years.

Agreed on renaming links folder.  Do it while you run the update and then name it back.  I have found the same thing with InSynch. 

Beth, it seems that I have to do that more and more in the last couple of years (rename Links). I'm not sure why since that has never been a problem in past years.

Beth, it seems that I have to do that more and more in the last couple of years (rename Links). I'm not sure why since that has never been a problem in past years.

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates read/write connection instead of a read-only one to the primary data file/table involved with that business object. This is only a problem but only when clicking Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd by design. That means if there's a MD override for it and that ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates a read/write connection to AR_Customer.m4t table/file.

Normally this is not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have and so you get the "file in use". Had the MD instantiated a service object AR_Custormer_svc instead of business object, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example they actually need to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if the StartProgram (as it's called) is CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)
------------------------------

@Alnoor Cassim If KnowledgeSync, Excel / F9 or other external program has an open connection to AR_Customer.m4t ( per your example), would the error occur?  Because these would be read only connections they shouldn't cause the exclusive access error? 

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates read/write connection instead of a read-only one to the primary data file/table involved with that business object. This is only a problem but only when clicking Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd by design. That means if there's a MD override for it and that ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates a read/write connection to AR_Customer.m4t table/file.

Normally this is not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have and so you get the "file in use". Had the MD instantiated a service object AR_Custormer_svc instead of business object, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example they actually need to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if the StartProgram (as it's called) is CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)

Doug you are correct those situations wouldn't cause the "in use" error. Any external app that uses ODBC is by definition a read-only connection. Now if the external app uses BOI, then if they're using AR_Customer_svc, they're still fine. But if it uses AR_Customer_bus because it needs to write back data, and the app is actively running at the same time you are updating UDFs, then we have a problem.

@Alnoor Cassim If KnowledgeSync, Excel / F9 or other external program has an open connection to AR_Customer.m4t ( per your example), would the error occur?  Because these would be read only connections they shouldn't cause the exclusive access error? 

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates read/write connection instead of a read-only one to the primary data file/table involved with that business object. This is only a problem but only when clicking Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd by design. That means if there's a MD override for it and that ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates a read/write connection to AR_Customer.m4t table/file.

Normally this is not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have and so you get the "file in use". Had the MD instantiated a service object AR_Custormer_svc instead of business object, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example they actually need to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if the StartProgram (as it's called) is CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)

Doug you are correct those situations wouldn't cause the "in use" error. Any external app that uses ODBC is by definition a read-only connection. Now if the external app uses BOI, then if they're using AR_Customer_svc, they're still fine. But if it uses AR_Customer_bus because it needs to write back data, and the app is actively running at the same time you are updating UDFs, then we have a problem.

@Alnoor Cassim If KnowledgeSync, Excel / F9 or other external program has an open connection to AR_Customer.m4t ( per your example), would the error occur?  Because these would be read only connections they shouldn't cause the exclusive access error? 

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates read/write connection instead of a read-only one to the primary data file/table involved with that business object. This is only a problem but only when clicking Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd by design. That means if there's a MD override for it and that ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates a read/write connection to AR_Customer.m4t table/file.

Normally this is not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have and so you get the "file in use". Had the MD instantiated a service object AR_Custormer_svc instead of business object, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example they actually need to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if the StartProgram (as it's called) is CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)

So, @Alnoor Cassim - I'm curious.  I had stopped the Sage service (this was on Adv) and was running Sage 100 in MAS90 mode.  I still got the error, until I renamed Links. Were the Credit Card and Avatax mods "actively running", in that instance?

Doug you are correct those situations wouldn't cause the "in use" error. Any external app that uses ODBC is by definition a read-only connection. Now if the external app uses BOI, then if they're using AR_Customer_svc, they're still fine. But if it uses AR_Customer_bus because it needs to write back data, and the app is actively running at the same time you are updating UDFs, then we have a problem.

@Alnoor Cassim If KnowledgeSync, Excel / F9 or other external program has an open connection to AR_Customer.m4t ( per your example), would the error occur?  Because these would be read only connections they shouldn't cause the exclusive access error? 

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates read/write connection instead of a read-only one to the primary data file/table involved with that business object. This is only a problem but only when clicking Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd by design. That means if there's a MD override for it and that ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates a read/write connection to AR_Customer.m4t table/file.

Normally this is not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have and so you get the "file in use". Had the MD instantiated a service object AR_Custormer_svc instead of business object, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example they actually need to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if the StartProgram (as it's called) is CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)

So, @Alnoor Cassim - I'm curious.  I had stopped the Sage service (this was on Adv) and was running Sage 100 in MAS90 mode.  I still got the error, until I renamed Links. Were the Credit Card and Avatax mods "actively running", in that instance?

Doug you are correct those situations wouldn't cause the "in use" error. Any external app that uses ODBC is by definition a read-only connection. Now if the external app uses BOI, then if they're using AR_Customer_svc, they're still fine. But if it uses AR_Customer_bus because it needs to write back data, and the app is actively running at the same time you are updating UDFs, then we have a problem.

@Alnoor Cassim If KnowledgeSync, Excel / F9 or other external program has an open connection to AR_Customer.m4t ( per your example), would the error occur?  Because these would be read only connections they shouldn't cause the exclusive access error? 

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates read/write connection instead of a read-only one to the primary data file/table involved with that business object. This is only a problem but only when clicking Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd by design. That means if there's a MD override for it and that ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates a read/write connection to AR_Customer.m4t table/file.

Normally this is not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have and so you get the "file in use". Had the MD instantiated a service object AR_Custormer_svc instead of business object, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example they actually need to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if the StartProgram (as it's called) is CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that bit in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates a read/write connection (instead of a read-only one) to the primary data file/table involved with that business object. This is only a problem only when we click Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd.pvc by design. That means if there's a MD override for it and their ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates the read/write connection to AR_Customer.m4t table/file.

Normally not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have now and so you get the "file in use". Had the MD instantiated the service object AR_Custormer_svc instead of AR_Custormer_bus, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example the MD needs to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if they detect the StartProgram (as it's called) as CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)
------------------------------

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that bit in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates a read/write connection (instead of a read-only one) to the primary data file/table involved with that business object. This is only a problem only when we click Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd.pvc by design. That means if there's a MD override for it and their ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates the read/write connection to AR_Customer.m4t table/file.

Normally not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have now and so you get the "file in use". Had the MD instantiated the service object AR_Custormer_svc instead of AR_Custormer_bus, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example the MD needs to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if they detect the StartProgram (as it's called) as CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)
------------------------------

@Alnoor Cassim  Why isn't this an issue with the base program as the "in use" error only happen when there is an override?  In Beth's example, if there wasn't an override and if she clicked update in UDF Maintenance why wouldn't that instantiate SO_SalesJournal_upd.pvc and AR_Customer_bus in the base programs and cause the same error? 

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that bit in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates a read/write connection (instead of a read-only one) to the primary data file/table involved with that business object. This is only a problem only when we click Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd.pvc by design. That means if there's a MD override for it and their ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates the read/write connection to AR_Customer.m4t table/file.

Normally not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have now and so you get the "file in use". Had the MD instantiated the service object AR_Custormer_svc instead of AR_Custormer_bus, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example the MD needs to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if they detect the StartProgram (as it's called) as CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)

@Doug Higgs that's an XLNT question. The answer is the Sage base classes for _UPDs never ever instantiate AR_Customer_bus or anything else (except for SO_Invoice_bus which are for the data entry tables). There are several _svc object connections done in the base class ON_CREATE. However, when it needs to write back to AR_Customer, or say to SO_SalesOrderHeader and SO_SalesOrderDetail for partial qty shipped backorder situations, or any of the history files and open invoice and trans pymt files that are touched, all of that is done directly with the ProvideX WRITE command. They don't use _bus objects at all during an Update (except SO_Invoice_bus). This is also the reason why scripts don't fire off during an Update.

An argument could be made the MD should also directly WRITE to AR_Customer OR do the same instantiate to AR_Customer_bus but not in the ON_CREATE block (do it another point in the update). A 3rd option would be to do it in the ON_CREATE but only if coSession'StartProgram$<>"CM_UDFMAINT_UI"
Which way is best practice? This is where we need official guidance from Sage engineers.

@Alnoor Cassim  Why isn't this an issue with the base program as the "in use" error only happen when there is an override?  In Beth's example, if there wasn't an override and if she clicked update in UDF Maintenance why wouldn't that instantiate SO_SalesJournal_upd.pvc and AR_Customer_bus in the base programs and cause the same error? 

Speaking with my MD hat on. This explanation will 99% not make sense and be clear as mud but here goes.

When an MD adds code in their override for an update program, such as SO_SalesJournal_upd.pvc, and when that includes instantiating a business object (for those of you who script, this is called GetObject or NewObject for the purpose of writing or reading to a different file/table), and the MD does that bit in what's called the ON_CREATE block of their override program, which sets initial variables and connections in their program, well that creates a read/write connection (instead of a read-only one) to the primary data file/table involved with that business object. This is only a problem only when we click Update in UDF Maintenance.

Using Beth's example of where she's sourced a AR_InvoiceHistoryHeader UDF from AR_TransactonPosting (which is the S/O Sales Journal Update), it will actually instantiate SO_SalesJournal_upd.pvc by design. That means if there's a MD override for it and their ON_CREATE block instantiates AR_Customer_bus as an object (as opposed to AR_Customer_svc), this creates the read/write connection to AR_Customer.m4t table/file.

Normally not an issue. However, UDF Maint during its update, will at some point want exclusive access to AR_Customer.m4t which it does not have now and so you get the "file in use". Had the MD instantiated the service object AR_Custormer_svc instead of AR_Custormer_bus, it would've create a read-only connection (akin to being in Customer Inquiry) which would not cause the "in use" msg. However, in this example the MD needs to write back to AR_Customer during the Sales Journal Update as part of their requirements, so they have to use AR_Customer_bus.

** A solution might be for the MD to not instantiate AR_Customer_bus (or whatever the _bus is) if they detect the StartProgram (as it's called) as CM_UDFMAINT_UI. Sage engineers should give the MDs some official guidance on this too as this issue has been around since Day 1 of Business Framework.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)