Note that these are in no particular order. See the Known Issues Index for an organized list.|
- Excel 2013 fails to fetch updates
Microsoft Office 2013 does not allow Basic Authentication over non-SSL connections by default. When using the Sablime add-on with Excel 2013 attempting to fetch updates results in an error dialog similar to the following:
Run-time error '1004':
More information can be found in
MS Support Article 2123563.
The suggested fix is to enable SSL on the Web Sablime server and use
https instead of http, however this requires changes to the
Excel workbook. Please contact
Sablime Technical Support
if you are interested in trying a version of the Sablime Excel workbook
with https support.
Unable to open
The hyperlink cannot be followed to the destination.
One of the following work-around should resolve the issue.
1) Continue using an older version of Excel.
2) Change the Windows registry settings as described in
to restore the old behavior and allow Basic Authentication over non-SSL
- Sablime v8.3 - Web Sablime IE11 Compatibility
Doing edget through Web Sablime v8.3 when using IE11 web browser does not
return any output or status from the edget command although the edget itself
and replace your existing file installed at
- Sablime v8.3 - Web Sablime MR details page
There are a couple issues with the MR details page in Web Sablime v8.3:
1) The list of current check-outs is missing the "File Name" header.
The remaining headers are shifted out of place so they do not line up
with the proper columns.
2) Switching between "Show All Deltas Per File" and "Show One Delta Per File"
in the file list causes an error from the web server similar to the
Script file /home/sabprod/sabbin/web/wsab/genDetails.pl&Zfiles=one is not found.
To fix both issues download
and replace your existing file installed at
- Email "from" address incorrect (comma in PTS name)
Many Sablime commands send email, and they set the "from" address of the email to the address found in the user's PTS record. Sablime uses the form Name<address>, where Name is the "Full Name" in the PTS record and address is the "Email Address" from the PTS record.
If the Name contains a comma, though (for example: "Riffle, Paul"), this causes the underlying sendmail utility to incorrectly mark the email as being from two users (for example, from "Riffle", and from "Paul<address>").
This problem will be fixed in Sablime version 6.1, Update 4.
Remove commas from the "Full Name" field in the PTS record.
- Source commands fail using SBCS and very large files
Sablime source commands (such as edget, sget, addsrc) may fail when using SBCS and when the file is very large. It has been observed that the file size Sablime can handle with SBCS as the version control tool is directly proportional to the amount of physical RAM on the machine, somewhere around 50%. That is, a file larger than 128MB is not safe to store in Sablime with SBCS on a machine with 256MB (or less) of RAM.
Use SCCS to store the file if possible.
Increase the amount of RAM on the machine.
Run the source operations from an NFS client that has more RAM.
- approve command fails with call_sccs message: bad p-file format(co17)
When there are an extraordinary number of deltas being approved
for a particular file, the Sablime approve
command may fail with a messages similar to the following:
+ Approving the specified MRs for the generic [1.0].
*SYS_ERR* Message Number  From: call_sccs.c [Version 18.104.22.168].
SCCS/SBCS command [get] failed, see DBA Warning file and
[/usr/tmp/call_sccs10762] file on host.
Please Notify Your Sablime System Administrator Immediately.
+ A Master Trace Record has been generated for the Database Administrator.
ERROR [/home/sablime/sdb/src/s.main.c]: bad p-file format (co17)
The "s." file mentioned in the error message is the system's master copy of the corresponding source file, including all the changes that have been applied.
The "p-file" is a lock file that the system constructs as it is trying to approve the MRs.
If the number of deltas is very large (it varies, but is somewhere over 100),
the system truncates the line in the p-file, resulting
in an improperly formatted p-file.
The utilities that perform these particluar operations are provided by the UNIX system vendor, so Sablime, unfortunately, can not fix this problem.
To avoid the problem, you can approve MRs more frequently and limit
the amount of times one MR is used to update (edget/edput) a file.
Depending on the situation there are three workarounds that could be applied after you've encounted the problem. These involve trying to reduce the number of deltas being approved at one time for this file.
1) If you are approving multiple MRS and more than one touches the file in question:
If using Sablime v6.0 or later, run the mk_approve command to produce a script for approving the smallest subsets of depedent MRs.
If you are not yet on v6.0, you can attempt to manually find smaller subsets of MRs to approve without encountering dependency issues.
If that isn't successful, you may have to find the set of MRs that touch this file and use the "depend" command to eliminate their dependencies on other MRs in the set. Approve these MRs, and then restore the dependencies.
2) If it is only one MR that touches the file many times, use "unedput" to remove deltas from the file (save away the copy of the file that unedput initially delivers to you). Once you've removed a sufficient number of deltas (assuming they were sequential and didn't have other MR deltas intermixed), you can "edget" the file and "edput" the copy you saved from the first unedput. This should restore the contents to where it was, but with fewer deltas. Then you'll be able to approve the MR.
3) If neither of the above can resolve the problem you may have to sget and save a copy of the file and then remove it from the generic by using the "source" command. You can then re-addisrc or re-addgsrc it. You will lose the MR history within this generic if you use this method