|
|
|
Thanks to all who took the time to recommend their city in the "Bring Expandability to your City" contest.
|
| At the 2008 Expandable Users Conference in San Francisco, attendees voted on which cities they thought we should look at for 2010. The top two cities ended up being Seattle and San Diego. |
| See the results of the voting |
|
|
| |
|
The following tips and examples provide SQL scripts to fix the problems related to common error messages. |
When executing SQL scripts we recommend beginning with a BEGIN TRAN statement. This is your safety net in case you typed the statement incorrectly or selected the incorrect table. You have not changed the DB until you execute a commit statement. If an error has been made, you can execute a rollback statement and no change to your DB will occur. |
| Too Many Concurrent Users |
 |
When the number of concurrent users signed into Expandable is at the maximum number allowed with your current licensing, you may receive the error “Too many concurrent users for this function.” This error means that the number of active users in the active_function_user table is already at the maximum allowable level. If you believe that you have not exceeded your concurrent licenses, the problem could be that active user records are “stuck” in this table because of either network or server issues. There are 2 ways to delete “invalid” active users like this in order to free up licenses. |
One way is through the Active User Editor in Expandable. (System — Security — Active Users Editor). |
However, you may not be able to log in to make these changes. In these instances, you can run a SQL statement against the license database. |
| A sample of such a script follows. (Note: The active_seed number would need to be replaced with actual data from your own licensing database table): |
| |
delete from active_function_user where active_seed='91028756' |
| Closed Dataset in Sales Order and Purchase Order Editors |
 |
|
|
Sometimes a situation may occur which results in a PO or an SO header being created with no associated line item records. When this happens, the above errors will be returned when trying to retrieve the order records with a QBE. These types of records can not be corrected from within the Sales Order or Purchase Order Editors. In order to clean this up in the tables, you must run a SQL script. |
For PO clean up, you can run the following script: |
|
delete from pofom where po_id not in (select po_id from pofod) |
For SO clean up, you can run the following script: |
|
delete from sofom where so_id not in (select so_id from sofod) |
| Tip: Deleting a custom report from the Report Manager |
Users familiar with the Report Manager in Expandable may have noticed that using the Delete Report option (accessed by right clicking on a custom report) does not always update the XXFPGM table properly. If an attempt is made to re-add a custom report deleted in this manner back into the Report Manager, an error stating that the report already exists in the system will occur (sample error screen shot follows): |
|
| To clear the deleted report completely from the table so that you can re-add it, you will need to use SQL. |
| A sample delete statement follows (replace the program ID with the one that you need to re-add in to the report manager): |
|
delete from xxfpgm where program _id='RMRBFV' |
Tip: Changes to the Plan Lead Time Field in the Part Master |
 |
| Please note: The MRP Generation Utility is using the Planning Lead to calculate when a part needs to be available. You should make sure the planning lead time is accurate before running the MRP Generation Utility. |
The Plan Lead Time (ICEPM) is the time in days it takes to order and receive a part from a vendor or the time it takes to order and receive a part from the plant. (Plan lead time = Vendor + Receiving lead times for a Buy part, Plan lead time = Kit + Manufacturing lead times for a Make Part). |
Many users already know that this field automatically calculates when a new record is being inserted. When a change to an existing part’s vendor, receiving, kit, or manufacturing lead time is made, users need to either recalculate the plan lead time and update the field manually, or run a SQL statement. The SQL statement method insures that all plan lead times in the part master are updated correctly. Execute both of the following statements to update all parts in the part master table: |
| |
update icfpm set plan_lead_time = (receiving_LT + vendr_lead_time) where part_type in (‘B’ , ‘X’) |
| |
update icfpm set plan_lead_time = (Mfg_LT + Kit_LT) where part_type in (‘M’ , ‘P’) |
Please note: The Cum Lead Time for buy parts should be equal to the Plan Lead Time. The Cum Lead Time for make parts can be calculated and updated by running the Cum Lead Time Rollup Utility located under Manufacturing, Product Data Control. Cum Lead time is used in the Master Scheduling Module. |
| |
|
|
|
|
|
|
