If you try to create a database from backup, and you specify a backup file name that does not end with ".bak", MainBoss adds ".bak" anyway. This means that if the file name really doesn't end with ".bak", MainBoss won't be able to find the file.
Due to a bug, you can only actualize demands one at a time—you cannot use multi-select features to select more than one demand and then actualize them. If you try to do so, you will get erroneous results that have to be correctly manually.
A problem occurs if you attempt to create a MainBoss Advanced database from MainBoss Basic data, and the MainBoss Basic data contains a Contacts table entry whose name exactly matches your login name. In this case, MainBoss Advanced crashes.
To get around the problem, you must edit the XML data produced by MainBoss Basic. You can do so with any standard text editor (e.g. Wordpad). Either change the name in the Contacts table so that it no longer matches your login name, or else delete the contact record completely.
There is a potential problem with the "Receive Acknowledgements" checkbox in the "Defaults for Requestors" section of Coding Definitions | Requests | Requestors. Due to a bug, the box may end up in a "null" state: neither checkmarked nor blank. On the screen, this is indicated either by a filled-in blue box or by the checkbox being disabled.
When "Receive Acknowledgements" is in this state, incoming e-mail messages from unrecognized requestors will be rejected. In the MainBoss Service event log, you will see an error message something like this:
Request from EMAIL ADDRESS rejected: Cannot insert the value NULL into column 'ReceiveAcknowledgement', table 'MB3.4Master.dbo.Requestor'; column does not allow nulls. INSERT fails. The statement has been terminated. Database table Requestor
To correct the problem, someone with Administration permissions should change the setting of "Receive Acknowledgements" to be either checkmarked or blank.
MainBoss uses Microsoft's ReportViewer to produce reports. In a small number of cases, ReportViewer will treat "#" followed by a string of characters as if it has a special meaning. For example, "#TOTAL" stands for the sum-total of values contained in the report.
This causes problems if anything in your data contains "#TOTAL", e.g. if some inventory item has "#TOTAL" in its name. If that item appears in a report, ReportViewer automatically prints out the calculated total in place of "#TOTAL", even though the number makes no sense in the name of an item.
Fortunately, there are only a few special cases like "#TOTAL". An arbitrary string like "#AYNX" has no special meaning, so ReportViewer leaves it as is. Nevertheless, we recommend that you do not use the "#" character in any type of data, including identification codes and descriptions.
When attempting to create a request using the Web Request module (submitting a request through a web page), a user might get the message
Cannot insert the value NULL into column 'SelectPrintFlag', table 'Database.dbo.Request'; column does not allow nulls. INSERT fails. The statement has been terminated.
This error can occur because the default checkbox for "Select for Printing" has been put into a state that is neither checkmarked or blank. This is an invalid state; when MainBoss tries to create a request using this default, it raises the given error and does not create the request.
To fix the problem, follow these steps:
When a task includes item demands in its resources, there are three options for determining the actual cost of the item: "Manual Entry", "Current value calculation", and "Demanded". The "Demanded" option tells MainBoss to calculate the item's actual cost based on price information as of the time when the demand is created.
This leads to problems if the item doesn't have any associated price information, which can happen if you have never recorded a price for the item or if the current inventory count is zero (in which case, the value is also zero). As a result, MainBoss can't calculate a price for the item, and therefore can't create a work order from the associated task. MainBoss will issue an error message saying that the work order couldn't be created.
To work around this problem, go to the task demand item record and changed "Demanded" into either "Manual entry" or "Current value calculation". MainBoss will then be able to create work orders from the task. Note that you may still have a problem if you choose "Current value calculation" and there is still no price information available at the time you actualize the item in a work order.
When you drop down a drop-down list, MainBoss does not pay attention to how long the list is in comparison to the window or the monitor screen. This means that the list may go off the bottom of the monitor screen, making it impossible to select some items from the list. You may be able to get around the problem by changing the window size and moving it higher up on your monitor screen. However, a more reliable approach is to click the associated "..." button; this opens a selection window which lets you avoid the problem.
If you've already created a receipt for all or part of a purchase order line item, you can't delete the line item from the purchase order, even if you cancel the receipt. (This problem may arise, for example, if you accidentally attribute a received item to the wrong purchase order.)
One way to deal with this problem is to edit the original line item to have a zero value, and to change the "Purchase Order Text" to something like "Line item deleted due to error". This isn't ideal, but at least it makes sure that your accounts are handled correctly and you have a note telling you what happened. You could use the associated "Comments" field to provide a more complete explanation of what happened.
If a task record has a purchase order template that includes outside labor, the template can't be removed from the task directly. Instead, you must go to Coding Definitions | Unit Maintenance Plans | Purchase Order Templates and edit the purchase order template in order to remove the outside labor line item from the template. Save the template. After that, you will be able to remove the template from the task.
If a table viewer is in "All" mode rather than "Active", various operations may not work if you attempt to make use of a deleted record. For example, in the Locations table, if you try "New Sub Location" to create a sub location of a deleted location, the resulting editor window will be in an anomalous state; you will not be able to close the window until you change the "Containing Location" field to a location that hasn't been deleted. Many other situations may occur, depending on what you try to do with a particular type of deleted record.
If you import item information from MainBoss Basic 2.9, the import process does not correctly set the cost centers in storage assignment records associated with the item.
If you delete a storeroom assignment and the minimum quantity for that assignment isn't zero, the Item Restocking report pays attention to that storeroom assignment when deciding if an item needs to be restocked. This means you may be told that the item needs to be restocked, even if all the undeleted storeroom assignments have sufficient quantities of the item on hand.
This will be corrected in a later release. In the meantime, if you want to delete a storeroom assignment, first set the Minimum quantity field to zero.
If you delete a user from the Users table, that user's SQL Server permissions on the MainBoss database are not deleted. Furthermore, the user record is not completely deleted; it is merely hidden (as is usually the case with records deleted from a table).
If you try to add the same user to the table again, the operation doesn't work—you'll be told that the table already holds a record for that user (even though the record has been deleted). However, if you attempt to restore the deleted record (using the Restore) operation, MainBoss doesn't try to create SQL Server permissions for the user on the database.
This arrangement is not a problem if you just delete a user, then add the same user again later on. Since the deletion didn't remove the user's SQL Server permissions, the permissions are already set up when you restore the user record. However, problems arise if you transfer the database from one SQL Server to another (e.g. using backup and restore). You can't add existing users to the transferred database (since the user records already exist in the table), and deleting/restoring user records doesn't create the necessary permissions in the new version of SQL Server. The only solution is to use SQL Server Management Studio to set up permissions manually.
MainBoss Service currently can't use POP protocols to interact with Office 365 mail. If you're using Office 365, you must use IMAPS.
Office 365 should be configured in a similar way to Outlook/Exchange. For more information, see our Tips for Configuring Outlook/Exchange.
Office 365 users should also note the "Invalid Mailbox Names" entry below.
The Incoming Mail section of a MainBoss Service configuration record contains a field called "Mailbox Name". If this field doesn't contain a valid name according to your mail server, MainBoss Service will terminate with an "Object not found" error. Inside MainBoss, this error will appear in the list of MainBoss Service messages (Administration | MainBoss Service). To correct the problem, you must specify a valid name in "Mailbox Name".
Note that if you leave the field blank, MainBoss uses the name INBOX. This is the default name used by Microsoft Exchange. However, it may not be valid with other mail servers.
If your organization uses domains, a computer may have domain users (who are known throughout the domain) and local users (who are only known on a single computer). When someone using MainBoss adds a new person to the MainBoss Users table, the person who is adding the new user must be signed on with an appropriate login name:
Problems arise if you try to add a user who doesn't have the same type as your own login name.
In general, we recommend that if your organization uses domain, you never have local users. This will avoid problems with MainBoss.
If you do a summary version of a maintenance forecast report, the count given is the count of unit maintenance plans used to create work orders, not the count of actual work orders. This will be corrected in a future release.
Due to a bug, this version of MainBoss will not print purchase orders that have no line items on them, unless you checkmark "Show Receiving" in the Advanced section of the report window. If you find that a purchase order isn't being printed, try checkmarking "Show Receiving".
This bug will be corrected in a future release.
In a purchase order, the "Work Orders" section should show work orders associated with the purchase order (if any). Instead, it shows information about the purchase order itself. This bug will be corrected in a future release.
The Work Order Summary report incorrectly calculates work order downtime. It adds the total downtime for a work order once for each resource on the work order; for example, if a work order has three items on it, the downtime will be added three times. The resulting downtime will therefore be a multiple of the true downtime. This bug will be corrected in a future release.
In the MainBoss Users table, a user name that doesn't have a value in the "Scope Name" field is intended to refer to all instances of that name, whatever the actual scope is. For example, if the user name is "jsmith" and "Scope Name" is blank, MainBoss will use that user record for any one with the login name "jsmith", regardless of the user's domain.
However, if the Users table contains a "scope-less" user record, and a record for the same user name with a scope, the record with the scope will always be used for users with the specified login name and domain. For example, if the Users table contains an entry for "DOMAIN\jsmith", that entry will always be used for someone logging in under DOMAIN\jsmith, even if the Users table also has a scope-less entry for "jsmith".
Some users have run into problems with this by accidentally creating multiple records for the same user: one scope-less, and one with an explicit domain name. The security roles associated with the explicit domain name record will always take precedence over the roles in the scope-less one, which may cause unexpected behaviors.
Due to an incorrect setting in MainBoss databases, various reports may not display hourly outside and per job outside costs associated with purchase orders.
It is possible to change the setting to correct the Purchase Order Summary, Purchase Order History Report, and printed purchase orders. To do so, follow these steps:
sqlcmd -S DatabaseServer -d MainBossDatabaseName -i scriptname.sqlwhere DatabaseServer is the name of the database server that manages your MainBoss database, MainBossDatabaseName is the name of the MainBoss database, and scriptname.sql is the full pathname of the file you downloaded in Step 2 above.
The output of the command will be "(1 rows affected)" or something similar. This indicates success.
You only have to do this once—it changes the appropriate setting in your database so that Purchase Order Summary reports work correctly.
Unfortunately, the problem will continue to occur in Receiving reports; the above fix is not enough to correct Receiving. However, Hourly Outside and Per Job Outside reports will provide the missing information.
This problem will be corrected in the next MainBoss release.
In some circumstances, using the "Repair" option for MainBoss Service (in the Windows control panel) may not actually correct existing problems. If you have problems with MainBoss Service, we recommend uninstalling, then reinstalling from scratch.
In the current version of MainBoss, if you set "Batch End Date" to a date in the past before you generate work orders, you will not generate any work orders. The reason is that if MainBoss finds that a job came due in the past, it attempts to schedule the job for today...but today would be after the specified "Batch End Date", so no work order is created.
In conversations with users, we have determined that it would be more useful if MainBoss didn't automatically try to schedule jobs for "today" in this situation. Therefore, this behavior will be changed in a future release.
The current version of MainBoss ignores options set in the "Printed Form" section of "Defaults for Purchase Order". For example, you can't change the default title line used when printing purchase orders. You can, however, change the title line used when you actually print purchase orders; just change the Title field in the "Advanced" section of the window for printing purchase orders. The same applies to other fields printed for POs.
If your license only allows a single user, you cannot change users by deleting the current user and putting in a different user. To change users, go to the Users table and click Edit to edit the existing user record. In that record, change the given User Name and adjust the Contact field so that it refers to the Contacts table entry for the new user.
As a side effect, all history records will be changed to refer to the new user name. For example, if you change from "Joe" to "Chris", all history records that used to refer to "Joe" (e.g. work order history records) will now contain "Chris" instead.
This problem will be fixed in a future release.
Some reports have built-in groupings. For example, the Work Order History report automatically groups by work order. If you sort by the same data as the automatic grouping (e.g. if you sort by work order in the Work Order History report), a bug makes the headers in the report disappear.
The workaround is simply to avoid this kind of sorting. It shouldn't be necessary, since the report is already grouped (and sorted) by this type of data.
The problem applies to the Work Order History, the Purchase Order History, the Request History, and all state history reports. The bug will be fixed in a future release.
If you attempt to set the scheduling basis for a unit maintenance plan, you might get the following error message:
Cannot insert the value NULL into column 'SinglePurchaseOrders', table 'AnotherFacility.dbo.PMGenerationBatch'; column does not allow nulls. INSERT fails. The statement has been terminated.
The problem arises because of a setting in the defaults for planned maintenance batches. To fix the problem, follow these steps:
You should now be able to set the scheduling basis for the desired unit maintenance plan.
If your organization requires the "null" option for Single Purchase Orders, you can set the checkbox back to its not-blank-or-checked state after you have set the desired scheduling basis.
This problem will be fixed in the next release of MainBoss.
A problem may occur in reports that let you include deleted records (i.e. where you checkmark Show deleted records in the Filtering section of the report window).
If you create such a report, and if you have an active record with the same name as a deleted record, then the report may combine information from the active record with information from the deleted record.
For example, suppose you delete a record for a unit named XYZ and later on, you create a new unit record with the same name. If you checkmark Show deleted records when you create a report about units, the resulting report may merge information from the deleted unit with information from the active unit; for example, unit history information will show information from both units as if they were a single unit.
Note that this only happens when you checkmark Show deleted records and only if you have a deleted record with the same name as an active one.
This problem actually occurs because of the way that older versions of MainBoss handled license keys. However, the problem only makes itself known when you install a newer version.
If you are running an older version of MainBoss and you license a MainBoss module that is newer than the version you are running, the license key will be marked as unusable. For example, the Web Access module was introduced in MainBoss 3.2 Update 1. If you enter a Web Access license key in a version of MainBoss that is older than 3.2 Update 1, MainBoss will issue an error message and mark the key as unusable. From that point on, all future versions of MainBoss will ignore the key. This will be true even for versions of MainBoss that are supposed to recognize Web Access license keys.
In order to get around this problem, you must delete the problem key. You can add the key again once you install a version of MainBoss that recognizes the key.
In some cases, it may be possible to have two or more license keys for the same module in your licenses list. This is because older versions of MainBoss did not check to see if a module had multiple keys. In this situation, MainBoss may not grant you access to the module; to fix the problem, delete all but the newest key.
When you use "Select Schedule Basis" to start a PM schedule for a unit, you should not choose a date that precedes all meter readings on the unit. If you do, MainBoss has a bug that will prevent PM jobs from being scheduled properly. Therefore, when you set the schedule basis, there must be at least one meter reading earlier than the date you specify.
This bug will be fixed in a forthcoming release.
Suppose that you have a task that includes several demands. If you change the task's expense model, the existing demands are not changed to reflect the new expense model. This means that the demands may refer to incorrect cost centers.
To work around the problem, you must edit existing demands after you change a task's expense model. Go to each demand, clear the expense category, then reset it. This will fix the demands so that they refer to the settings associated with the new expense model.
After you install MainBoss Advanced 3.4 Update 2, you can run MainBoss without upgrading your database—the software does not require the upgrade. (Note that this only applies if you are currently running MainBoss 3.4 or MainBoss 3.4 Update 1. If you are running an older version of MainBoss, you will be required to do the upgrade when you install MainBoss Advanced 3.4 Update 2.)
If you do not upgrade your database, you may run into mysterious errors:
To fix such problems, upgrade the database.
Due to a bug, the "WorkOrderClose" security role is not sufficient for someone to set a closing code for a work order. This will be corrected in a future release.
If you do not have an Inventory license key, you can create temporary storage locations for work orders and you can create temporary storage assignments, but you cannot actually put items into such temporary storage. As a result, the temporary storage can't actually be used for anything.
The New Purchase Item window lets you select multiple line items simultaneously. However, you can only specify the cost of one of those items, and the cost you specify will be taken as the price for all the items you choose. This is almost never what you want.
Because of this, you should avoid choosing multiple line items. Specify one item at a time so that you can specify quantities and costs appropriately.
At present, New Work Order From Task does not work in the Tasks table viewer, or in any other window in which it appears. If you want to create a new work order from an existing task, we suggest you create a unit maintenance plan for the appropriate unit, using the task you want to execute and a maintenance timing record that has no contents (i.e. no date or meter specifications). You can then create the work order you want using Create unplanned Maintenance Work Order in the Unit Maintenance Plan table viewer.
This problem arises if there's something wrong with the computer named in the Machine Name field of your MainBoss Service configuration. When the MainBoss program starts up, it contacts the given computer to obtain information about MainBoss Service. If the computer doesn't respond, MainBoss will wait for a considerable length of time before finally giving up. As a result, several minutes may pass between the time you start MainBoss and the time MainBoss finally appears on your screen. To correct the problem, change the Machine Name.
Note that the problem does not occur if the given computer responds in any way...even if the computer's response is that it's busy or that it is refusing all queries. The problem only occurs if the computer doesn't respond at all, in which case MainBoss waits several minutes before giving up.
If, for any reason, a MainBoss session disconnects from SQL Server, MainBoss doesn't attempt to establish the connection again. A disconnect can happen for many reasons; for example, the computer where SQL Server is running may go down or may be temporarily unplugged from your network. Also, if you do nothing with MainBoss for a long time (at least half an hour), SQL Server may "time you out", which means that SQL Server cuts your connection because you've been idle too long.
In such cases, MainBoss should probably try to reestablish its connection; the current version doesn't. Instead, you'll just get an error message: "Unable to refresh browser list contents; click the Refresh button to try again." If you click the "Details" button on the message window, you'll see something like "A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)" In some cases, you may get a different message that may not be very clear on what has actually gone wrong. The only way to fix the problem is to quit your current MainBoss session and start a new one.
If you filter state history reports by creator, the output only shows records created by that person, not by anyone else. For example, suppose that you want information on all work orders where Pat made a comment. The report will only show comments from Pat; you will not see comments created by anyone else. Technically speaking, this might be correct, but in general, you likely want to see all the "conversations" in which Pat took part, not just Pat's side of the conversation.
The same applies when you filter by state or status code. For example, you only see state history records with a given status code, not other history records for the same work order.
Suppose you are using a filter to look at Work Orders (e.g. you are only looking at work orders with a given priority). If you click the Print button, the resulting report ignores the filter you were using (e.g. you see work orders of all priorities).
You can, of course, set the filters for the report to match the filters you were using when looking at the table. However, we believe it would be better if the table viewer's filter carried over to the report in this situation. Such a facility may be implemented in a future release.
A similar problem happens with the Active filter on work orders. In a table viewer, the Active filter only applies to closed or void work orders; it never filters out open work orders, no matter how old they are. In a report, however, the Active filter is applied to all work orders, whether or not they're open. This may mean that you can see a work order in the table viewer, but when you try to print out that work order, the resulting report shows nothing. To get around this problem, go to the Advanced section of the report window and checkmark Suppress Active Filter restrictions. You can then print "old" work orders that show up in the table viewer but not in the report.
The same sort of problem occurs with requests and purchase orders.
When MainBoss starts up, it checks your monitor screen's resolution. From that point on, MainBoss sizes its windows to fit that resolution. If you change your monitor's resolution while using MainBoss, MainBoss's windows will not change to match the new resolution. This may have various effects, e.g. information disappearing off the bottom of the screen with no easy way to get it back. However, if you maximize any window (by clicking the maximize button in the window's upper right-hand corner), the maximization will be correct because that's handled by Windows rather than MainBoss.
If you run into window sizing problems because of this, just quit MainBoss and start it up again. MainBoss will then take note of the new screen resolution and size windows appropriately.
Note that the minimum supported resolution is 1024 by 768. Ideally, we recommend 1280 by 1024 or better.
If you have the MainBoss Administration security role, you can use Administration | Users to try to add a new user to MainBoss. However, you must also have SQL Server Administration permissions for the operation to succeed. If you don't have these permissions, you'll get the error message
User does not have permission to perform this action. The statement has been terminated.
Since the problem is that you don't have SQL Server permissions, you can't fix it by giving yourself more MainBoss permissions.
There are several ways to fix the problem.
Requests, work orders and purchase orders are numbered automatically based on a starting value given in the "Defaults" section of the table viewer (e.g. "Defaults for Requests" in the Requests table viewer). You specify the number in the "Number Sequence" field; this number increases every time you create an automatically-numbered request, work order or purchase order.
If "Number Sequence" ever comes to a number that has already been used, you will get an error when you try to create a request, work order or purchase order with that number. The error message begins with the string "Violation of UNIQUE KEY constraint". When this happens, "Number Sequence" will not be increased (because MainBoss didn't manage to create anything with that number). Therefore, the next time you try to create an automatically-numbered request, work order or purchase order, you'll get the same error message because of the duplicate number.
To get "unstuck", go to the appropriate defaults section and click "Edit Defaults". Set the "Number Sequence" to 1, then click "Save defaults". Immediately, set the "Number Sequence" to a value higher than any numbers that are already in use. Click "Save defaults" again. From this point on, you should have no trouble creating automatically-numbered requests, work orders or purchase orders.
For any report, you must checkmark at least one of the Show checkboxes in the Advanced section. Otherwise, the report will contain no output. This applies, even for "summary" reports that do not show any of the usual data—you must checkmark at least one Show box or the report will be blank.
To export data to Excel, MainBoss uses Microsoft Report Viewer. With some reports (e.g. Unit Maintenance Plans), the resulting Excel spreadsheet may have the Row Height set too small for some data fields.
To solve the problem, select the entire spreadsheet then use the AutoFit Row Height operation. This is typically found on the Home ribbon; use the drop-down arrow associated with the Format button in the Cells section, then select AutoFit Row Height from the menu.
When you first go to a report preview, the zoom mode is set to 100% and the page layout is set to list mode. Due to a problem with Microsoft Report Viewer, if you set the zoom mode to "Whole Page", the result is typically unreadable; "Whole Page" is only suitable for use if you set the page layout to page mode.
Due to a bug, the Save & Close operation can result in false concurrency errors when you're actualizing resources. The way around this problem is to click Save and then Close separately, rather than Save & Close.
In work order demands, there's a field for specifying an expense category. The drop-down menu and the "..." for that field make it possible to create a new expense category; however, if you use these facilities to make a new expense category it doesn't get you anywhere.
To understand why, remember that the expense categories available for a work order are dictated by the current expense model. If you create a new expense category, that category won't be part of the expense model already chosen for the work order. Therefore, you won't be able to use the category you just created.
Instead of the current behavior, MainBoss should make it possible to add a new expense mapping to the current expense model. This would make another expense category available for use on the work order; this is usually what you want, as opposed to a brand new expense category.
Some versions of SQL Server run into errors where PM Generation fails because of "time-out" problems. You can deal with such problems (and increase the speed of Planned Maintenance generation) by following these steps:
CREATE NONCLUSTERED INDEX [ScheduledWorkOrderID] ON [dbo].[PMGenerationDetail] ( [ScheduledWorkOrderID] ASC )WITH (STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO
Microsoft SQL Server has various ways to optimize performance speed. In particular, it maintains indices and statistics that help it obtain information as fast as possible. Unfortunately, these can get messed up, leading to slower performance. If this happens, rebuilding the indices and statistics can significantly improve MainBoss's speed.
To rebuild a database's indices and statistics, follow these steps:
declare @cmd nvarchar(max) set @cmd = '' select @cmd = @cmd + 'UPDATE STATISTICS ['+name+']'+char(13)+char(10) from sys.tables select @cmd = @cmd + 'ALTER INDEX ALL ON ['+name+'] REBUILD'+char(13)+char(10) from sys.tables exec sp_executesql @cmd
Management Studio will open a second window with sections named "Results" and "Messages". Management Studio will then update the statistics and rebuld indices; this may take several minutes, depending on the size of the database.
When the process is finished, you should see the message "Command(s) completed successfully." You can then quit Management Studio.
In some cases, the Update Licenses facility for updating multiple licenses can issue an error message "Incompatible License Model Exception" when you are trying to add new license keys. In this case, delete all the old license keys and then add the new ones.