SoftArtisans ExcelWriter Guide

Troubleshooting Guide

Installation problems
1. Auto installation program fails to complete successfully
2. Manual registration of the SAEXCEL.DLL fails
Common server-side code execution errors
Problems related to saving or opening ExcelWriter generated files

Installation problems
1. Auto installation fails
  To install any version of ExcelWriter other than ExcelWriter Desktop, you must have either MTS (NT4) or COM+ (Windows 2000), and Peer Webserver, Personal Web Server, or IIS 4/5.
  
  If the necessary software is installed on your machine, but the installation fails, make sure that the downloaded package contains a valid signature from SoftArtisans:
  - Right-click the exe file that you downloaded from SoftArtisans, and select Properties.
  - Select the Digital Signatures tab.
  - Select the entry in the Signature List box.
  - Click Details.
  - Select the General tab.
  - Under the heading Digital Signature Information, you should see This Digital Signature is OK. If you do not see this confirmation, delete the exe and try to download again. If the second exe also appears to be corrupted, contact us.
2. Manual registration of SAEXCEL.DLL fails
  When attempting to manually register SAEXCEL.DLL on your server, you may recieve an error message: "Load Library "SAEXCEL.DLL" failed..." or "DLLRegisterServer in saexcel.dll failed. Return code was: 0x8002801c".
  
  If this occurs, the first thing to check is that SAEXCEL.DLL is installed in the location where you are attempting to manually register it. If SAEXCEL.DLL is there but does not register successfully, then verify that the role under which you are logged on to this server has the proper authority to register or unregister .dlls in general. If you have proper permissions, but this process still fails, you will need to verify that the "System" account has proper access to the type library associated with this .dll. (see issue IIa below)
Back to top
Common server-side code execution errors
1. Instantiation of ExcelWriter Application Object fails
  After installing ExcelWriter to your server and attempting to run either the sample code included with the product, or your own code, you may experience the following error:
  
  "Active Server Pages error 'ASP 0223' TypeLib Not Found.
  The METADATA tag contains a Type Library specification that does not match any Registry entry."
  
  This error is often caused by improper permissions in the Registry, but may also indicate that the auto installation process failed to register SAEXCEL.DLL successfully.
  With a typical installation, the auto installer places "SAEXCEL.DLL" into the "C:\Program Files\SoftArtisans\ExcelWriter" folder and attempts to register it there. It creates the following type library:
  HKEY_CLASSES_ROOT\TYPELIB\{7BCD2133-64A0-4770-843C-090637114583}
  When the <METADATA> tag included in the sample code page attempts to access the referenced TypeLib, the attempt will fail if this TypeLib does not have the proper permissions established for the logged on user to access this resource. For security reasons, our installer does not make any modifications to existing permissions in the registry. Typically, when your application is running under Anonymous Access, it is the "IUSR_Machinename" (or the "Everyone") account which must have read access to this TypeLib.
  Follow this procedure to verify if the ExcelWriter TypeLib contains the proper permissions:
  - Go to "Start/Run" and type in "REGEDT32". This will open the Registry Editor
  - Maximize the "Hkey_Classes_Root on Local Machine" window
  - Scroll down until you locate the "TypeLib" folder
  - Expand this folder by double-clicking the "+" sign. This displays a list of installed keys
  - Locate the ExcelWriter key: {7BCD2133-64A0-4770-843C-090637114583}
  - Highlight this key by clicking once on it and go up to the "Security Menu" at the top
  - Choose "Permissions" from the drop down menu
  - Verify that the "Everyone" account is listed in the "Name" window
  - If the "Everyone" account is not part of this list, it should be added as follows:
    (for Windows NT4)
    - Click "ADD"
    - Double-click "Everyone"
    - Leave the default type of access as "Read"
    - Click "OK" to dismiss the Add dialog.
    - Make sure to select "Replace permissions on Existing Subkeys"
    - Click "OK" for the new permissions to take effect
    (for Windows 2000)
    - Click "ADD"
    - Double-click "Everyone"
    - Check the "Query Value", "Enumerate subkeys", "Notify", "Read control" checkboxes
    - Check "Apply these permissions to objects and/or containers within this container only"
    - Make sure the drop down "Apply onto" is "This key and subkeys"
    - Click "OK" to dismiss the dialog box
    - On the Access Control Setting for {7BCD2133...", make sure "Reset permissions on all child objects and enable propogation of inheritable permissions" is checked
    - Click "OK" to continue
    - A warning dialog will come up ("This will remove explicitly yadayadayada")
    - Click "YES" and then Click "OK" for the Permissions dialog
    - Click "Apply"
  - Verify that the "System" account has "full control" over the type library. If it does not, simply follow the procedure above and substitute this account for "Everyone" and "full control" for "read".
  - Once the hourglass goes away, you can close the Registry Editor.
  Then, reboot your system, and rerun the code to determine if the installation is now working properly. If it continues to fail, please contact us.
2. Attempting to use a property or method returns "Object doesn't support this property or method..." error
  ExcelWriter, as a web reporting tool, can be purchased in two major editions: ExcelWriter (full server) or ExcelWriterLE. The LE edition provides a limited subset of methods and properties that are available in the full edition.
  
  Quite often, when using ExcelWriterLE, developers attempt to access methods or properties not available in this edition. Although ExcelWriterLE should generate a user-friendly error advising of this limitation, the code may generate an "Object doesn't support this property or method..." error instead.
  
  If this occurs, then verify that the referenced property is available to LE users by checking the Object Model to be sure that this property or method is not appended with a red asterisk (i.e. NamedRange*).
  
  If the object or method should be available, then check the syntax of the calling code. If this does not resolve the issue, please contact us.
3. Code executing on the server throws an "ASP 0115" error
  When executing script on the server, the code may suddenly stop running and generate an error message such as:
  
     Error 'ASP 0115': Unexpected error
     /excelwriter/ReportGen.asp
     A trappable error occurred in an external object. The script cannot continue running.
  
  Unfortunately, the cause of this server-side exception can be difficult to isolate. Quite often, the cause is associated with a scripting syntax error of some type. This can be something as simple as using incorrect spelling for a constant or an erroneous attempt to reference a method or property.
  
  The first suggestion would be to step through your code using a debugging tool in order to attempt to isolate an offending line of code. Using an error handler such as "On Error Resume Next", may allow you to generate your output file and to locate missing or erroneous data.
  
  If this fails to locate the cause, then, attempt to identify as much information as to the circumstances under which the error is occurring. A good source of data related to this exception is often provided by the logs available as part of the Event Viewer on the server. Any applicable exception logs should be forwarded along with a request for assistance to the SoftArtisans support department. Be sure to include server configuration information and any scripts used in the application.
  
  Please note: in order to minimize server crashes that may be associated with this error, it is recommended that the web application that hosts the ExcelWriter functionality should not be configured to use the "Application Protection" setting of "Low(IIS Process)" unless abolutely necessary. Rather, it is suggested to use, at the minimum, the setting of "Medium(pooled)" whenever possible. This "Application Protection" setting is available in IIS 5 (Windows 2000) as follows:
  - Go to the Internet Services Manager (IIS Console) on the server
  - Right-click the virtual directory that contains your ExcelWriter code pages
  - Choose "Properties" from the popup menu
  - In the bottom "Application Settings" frame of the "Virtual Directory" tab, locate the "Application Protection" setting
  - Click the dropdown list and select either "Medium(pooled)"
  - Click "Apply" and "Ok" twice to close out with changes intact
  - Stop and restart the web services for this change to take effect
  Applications that are configured with "Low(IIS Process)" share the same portion of server memory. A fatal error in an application can bring down all of the other applications in the shared area of memory within IIS, and, possibly, IIS itself.
Back to top
Problems related to saving or opening ExcelWriter generated files
1. Downloaded file displays as blank screen
  When ExcelWriter attempts to stream a newly created native Excel file to a client machine for opening in the browser or directly in Excel on the client machine, the browser displays a totally blank screen and no error is generated.
  This most often occurs when either of the following Save methods: "saOpeninPlace" or "saOpenInExcel" are specified with constants as parameters:
  
  XLW.Save "myreport.xls", saOpenInPlace
  XLW.Save "myreport.xls", saOpenInExcel
  
  and you have failed to include the <METADATA> tag at the top of the coded page as follows:
```
<%@ Language=VBScript %>

<% Set xlw = Server.CreateObject("Softartisans.ExcelWriter")
...	
%> 
```
  The <METADATA> tag makes use of the ASP TypeLib facility. Typelibs provide a convenient and faster means to access constants associated with a particular object instead of #include files or arbitrary values. Since most of our examples use constants for clarity (saOpenInPlace, saOpenInExcel), the TypeLib is included near the top of our code. The unique identifier ( UUID ) is specific and unique to SoftArtisans ExcelWriter.
  
  SoftArtisans recommends the use of constants from the ExcelWriter Type Library whenever possible. If you use these constants, you must include the <METADATA> tag at the top of your code. If you do not use the Type Library, you must be certain that you are using the correct and appropriate hardcoded values of "1" (saOpenInExcel) or "2" (saOpenInPlace).
2. Downloaded file contains "gibberish" or does not display as Excel content
  When attempting to stream a newly created native Excel file to a client browser with ExcelWriter's "saOpenInPlace" Save option, the anticipated Excel output is replaced by gibberish in the browser.
  
  Instead of launching Excel within the browser in order to display the Excel file, the browser treats the contents as HTML and displays the gibberish which is composed of strings of data that look something like the following:
```
...÷.… o. .Ticket Salesüà ..Week 1..Week 2..Week 3..Week
```
  The most common cause of gibberish appearing in the client browser in lieu of the expected Excel file is the inclusion of "Response.Write" statements into the ASP code which instantiates ExcelWriter and formats the new Excel file "on the fly" server-side.
  
  Any attempts to write back HTML content of any type (i.e. message text, tags) will mix non Excel content into the download stream and corrupt the "ContentType" of the transmission. It is the "ContentType" which advises the browser which application to launch in order to interpret and render the content correctly.
  
  If your ExcelWriter ASP page contains Server-Side Includes, you must be sure to verify that these includes do not contain any attempts to generate HTML output either, or the same garbled results will occur.
  
  One additional factor which can cause this problem is if you have server-side debugging turned on for your ExcelWriter application. To check this:
  - Go to the Internet Services Manager (IIS Console) on the server
  - Right-click on the virtual directory that contains your ExcelWriter code pages
  - Choose "Properties" from the popup menu
  - In the bottom frame of the "Virtual Directory" tab that contains the "Application Settings", click the "configuration" button
  - Click on the "App Debugging" tab
  - If either debugging flag is enabled, uncheck it
  - Click "Apply" and "OK" twice to close out with changes intact
3. Downloaded file displays source code instead of Excel output
  If the ExcelWriter server-side script uses "saOpenInPlace" to stream the newly created file to a client machine for opening directly with Excel in the browser window, and the file displays the ASP source code from the download page, there are a couple of known causes that warrant investigation.
  
  If the download page that instantiates ExcelWriter and creates the Excel file being streamed ends in the ".asp" extension, then you must be sure that this ".asp" extension has been associated with the ASP.DLL for the web application that contains your code page. To check this, do the following:
  - Go to the Internet Services Manager (IIS Console) on the server
  - Right-click on the application containing the ExcelWriter code page
  - Choose "Properties" from the popup menu
  - In the bottom frame of the "Virtual Directory" tab that contains the "Application Settings", click the "configuration" button
  - Click on the "App Mappings" tab
  - In the "Application Mappings" drop down list box, locate an entry for the ".asp" extension"
  - Verify that the ".asp" extension has been associated with the ASP.DLL
  - If this association is present, then simply cancel out of the dialog boxes.
  - If this association is missing, then click the "Add" button
  - Browse to select asp.dll, typically in c:\winnt\system32\inetsrv.
  - Enter "asp" in the Extension text box.
  - Select "All Verbs."
  - Check "Script Engine."
  - Do not check "Check that file exists."
  - Click "Apply" and "OK" twice to close out with changes intact
  - Stop and restart the web server and retest the code
  If you are using the Configuring IIS solution as part of your application, please recheck the steps included in the documentation in order to insure that the ".xls" extension has been properly associated with the ASP.DLL for code pages renamed to end in this extension.
  
  Another common cause is associated with the use of Excel 2000 on the client machine where the installation of Service Release 1 has not been included. Microsoft has acknowledged known "bugs" in Excel 2000 that were later corrected by applying SR-1. One of these "bugs" is related to the display of source code in place of the expected Excel data. The problems associated with using Excel 2000 pre-SR1 to view downloaded files directly in the browswer are covered in-depth in our Knowledge Base for ExcelWriter located on our support site. Refer to article #191.
4. File Download dialog displays when not required or an extra dialog appears
  If the ExcelWriter server-side script uses "saOpenInPlace" to stream the newly created file to a client machine, and the file launches a "File Download" dialog on the client machine rather than opening directly in browser, the cause may be covered below.
  
  There is a security setting that is part of the client-side file system which prevents downloaded Excel files from opening automatically without the consent of the viewer. In order to see if this setting is active, or to manaully disable this setting, do the following:
  - Right click on the "Start" button and select "Explore" from the popup menu
  - Click the "Tools" menu and select "Folder Options" from the dropdown menu
  - Click the "File Types" tab. A list of the file extensions should appear
  - Locate the ".xls" extension, highlight it, and click the "Advanced" button
  - In the "Edit File Types" dialog, you should see a "Confirm open after download" with an associated check box
  - If this is enabled, this is probably the cause of the unexpected "File Download" dialog
  - If the user is willing, they can uncheck this box to remove this security feature
  - If changes are mode, then click "Apply" and "OK" twice to close out with these intact
  - Otherwise, to keep current settings, simply cancel out of all dialog boxes
  Another known cause of the failure for Excel content to display properly when using the "saOpenInPlace" Save option, is related to the use of early releases of Internet Explorer 5.5. Microsoft has acknowledged known "bugs" in this browser that were related to its inability to understand the content type of files that it receives in a download. This can be corrected by downloading recent versions of this browser or by applying security patches or Service Releases to the earlier releases. This is covered in-depth in our Knowledge Base for FileUp (the SoftArtisans HTTP download control) located on our support site. Refer to article #117.
Back to top