CHM does not create any content in file

kzakoskikzakoski Posts: 10
edited July 17, 2015 10:47AM in SQL Doc
I've tried a number of different databases, small and large. I can successfully create HTML documentation. However, when I try to create the CHM documentation, it creates the compiled help file successfully, but when I open the file the table of contents and index info display like my HTML documents, but selecting an item does not display anything and all I get is a blank page.

I'm running on Wndows 7, 64bit machine and have HTML Help Workshop 1.4 installed.

The database I need to document is large and creating DOC and PDF documents encounter the 'Out of Memory' error I've seen if a couple of posts. Any help or info would be greatly appreciated.
· Share on Twitter

Comments

  • Rob CRob C Posts: 419 Gold 2
    Hi,

    Which version of SQL Doc are you using? The latest is 3.0.3.9 - if you are not already running this version, can you update it and see if you still have the problem?
    Software Engineer
    Redgate Software
    · Share on Twitter
  • BitsqueezerBitsqueezer Posts: 1
    Hi,

    I have the same issue with the newest version 3.0.3.9.

    The first try was to create a documentation of the complete database to CHM which worked without problem. Then I wanted to exclude some of the objects and only document some of the SPs and UDFs which resulted in the issue that the CHM file only displays the objects in the contents but the right side is always empty.
    It seems that the "Documenting" step in case of CHM executes very fast in comparison with the other three variants.

    Other issues:
    • The project logo is not included in any documentation output file (big icon in my case) except HTML. If icons are supported there should also be a way to select the icon as there could be more than one and with different resolution/colors in one icon file.
    • PDF has very large margins, would be better to set them very small to get more on a page
    • The Word file sometimes uses a right margin and word wrapping when scripting objects and sometimes there is no margin and no word wrapping so longer rows cannot be seen (only with i.e. copy/paste into another document). It seems it has something to do with rows which contains non-wrappable text like this:
      -- ===================================================================================================================================
      which I sometimes use as header line for my SPs.
    • HTML generates a lot of single files, why doesn't it use the MHT variant like Internet Explorer has as standard type now? With single files the creation of documentation is really very slow.
    • In HTML documentation the script is in divs (<div class="panel-body"><div id="sqlScript">) which has the problem that the horizontal scroll bar is at the bottom of the script window which only can be seen if the outer frame's vertical scroll bar is moved to that position. Means: If I see a row which is longer than the display window of the browser and want to scroll to the right I must scroll all the way down to see the horizontal scroll bar, then I can see the text but it is now all the way up so I must scroll back to find where I was before... that makes no sense to view such a documentation. Instead of pasting all paragraphs into one view window it would be better to create x sub-nodes in the tree under each procedure for each paragraph like "header information", "script", "uses" or something like that. On that way the script window can use the complete frame and so also the frame scrollbars. (The same issue exists if no frames are used.)
    • Using the MS_Description extended property is of course a good way to include that in the documentation - but not in case of parameters of stored procedures. Although it would be possible to write all the explanations here, no developer would do that. If you write a stored procedure or anything else which needs parameters anyone of course write comments to the parameters into the script itself.
      A really helpful extension to the documentation tool would be if you declare a standard way to prefix/suffix parameter description into SQL Prompt so we can create a procedure header with a click or shortcut like this:
      -- =======================
-- &lt;Author&gt;: Name
-- &lt;Date Created&gt;: 17.07.2015
-- &lt;Date Last Change&gt;: 17.07.2015
-- &lt;Description&gt;: My really important stored procedure
-- &lt;Parameters&gt;: &lt;@ID_Customer&gt;: The ID of the customer
--               &lt;@Errortext OUTPUT&gt;: Returns a translated error text for the frontend
-- &lt;/Parameters&gt;
-- &lt;Returns&gt;: A list of invoices of the specified customer ID
-- &lt;Error Codes&gt;: &lt;0&gt;: Everything OK
--                &lt;-1&gt;: Customer ID doesn't exist
--                &lt;-2&gt;: Customer has no invoices
-- &lt;/Error Codes&gt;
CREATE PROCEDURE dbo.Customer_GetInvoices
    @ID_Customer     int,
    @Errortext       nvarchar(MAX) OUTPUT
AS
BEGIN
   DECLARE @ReturnCode AS int; -- &lt;RETURNCODE&gt;
...
   SET @ReturnCode = -1;
...
END
      SQL Prompt can easily parse the SP for parameters and insert that into the header, it also can provide all the other infos using settings (like author name or which date/time/format to insert etc.), it can scan the text for the <RETURNCODE> tag to get the variable name @ReturnCode and scan the rest of the script for any SET/SELECT to a constant value and insert that also as error codes into the header.
      SQL Doc could then easily scan the procedures for these tags and insert everything into the documentation of the parameters, header informations and return codes. Would make the life of developers really a lot easier and other IDEs already use such things like Java documentation comments and so on. I saw a similar method today here: http://www.innovasys.com/product/dx/dat ... umentation

    Would be great if the CHM issue could be fixed as currently that seems to be the best documentation output type.

    Best regards,

    Christian
    · Share on Twitter
Sign In or Register to comment.