/build/static/layout/Breadcrumb_cap_w.png

Workaround for Line Break Character Bug in Reports Generated on Inventory Custom Fields

After reading a bit on MySQL commands, I thought I'd try to get this aesthetic thorn out of my side.  Rather than bury this in an old post:

Extending the Dell KACE K1000 System Management Appliance's Computer Inventory to Support User Profile Specific & Other Non-Inventoried Data

http://www.itninja.com/question/extending-the-computer-inventory-to-support-user-profile-specific-other-non-inventoried-data

I put it here so it would hopefully be more visible.  For anyone who is reporting on Custom Fields populated by ShellCommandTextReturn, you can use this workaround to clean up your report output.  Unfortunately, there is apparently still a bug in the (new) Reports engine which isn't processing the MySQL line break character (tried both \n and \r\n), however if you have access to the Classic Reports module, that processes everything correctly (albeit without the automatic column sizing - have to tweak the HTML if you want it a little more pleasing to the eye; I covered this in another one of my posts, if you want to know how to do that).

Anyways, I started with the SQL code from a Custom Fields report generated by the Report Wizard.  If you look at the output, you will see that the line breaks are not being processed correctly (show up as <br/>).

_____________________________________________________________________________________

1) Original generated by Report Wizard:

SELECT MACHINE.NAME AS SYSTEM_NAME,IP, (SELECT MACHINE_CUSTOM_INVENTORY.STR_FIELD_VALUE FROM MACHINE_CUSTOM_INVENTORY WHERE MACHINE_CUSTOM_INVENTORY.ID=MACHINE.ID AND MACHINE_CUSTOM_INVENTORY.SOFTWARE_ID=6914) AS MACHINE_CUSTOM_INVENTORY_0_6914 FROM MACHINE     ORDER BY SYSTEM_NAME

_____________________________________________________________________________________

Output:

3 JSMITH 192.168.1.50 4/10/2012 8:03:52 AM - Logged in user: jsmith<br/>------------------------------------------------------<br/>C: Local Hard Drive<br/>D: CD/DVD Drive<br/><br/>

_____________________________________________________________________________________ _____________________________________________________________________________________

2) I added REPLACE statement to swap <br/> for line breaks (\r\n).  The line break characters are not processed correctly by (new) Reports engine (BUG?).  However, all instances of <br/> removed (so it is cleaner).

SELECT MACHINE.NAME AS 'Machine', REPLACE((SELECT MACHINE_CUSTOM_INVENTORY.STR_FIELD_VALUE FROM MACHINE_CUSTOM_INVENTORY WHERE MACHINE_CUSTOM_INVENTORY.ID=MACHINE.ID AND MACHINE_CUSTOM_INVENTORY.SOFTWARE_ID=6914), '<br/>', '\r\n') AS 'Local And Network Drives' FROM MACHINE     ORDER BY Machine

_____________________________________________________________________________________

Output:

JSMITH 4/10/2012 8:03:52 AM - Logged in user: jsmith ------------------------------------------------------ C: Local Hard Drive D: CD/DVD Drive

_____________________________________________________________________________________ _____________________________________________________________________________________

3) Same SQL Select statement (w/REPLACE statement) run from Classic Reports engine.  Everything is processed correctly, so there must be a bug in the (new) Reports engine. Example output below run without "Break on Columns" for cleaner example

_____________________________________________________________________________________

Output:

3             JSMITH                                                     4/10/2012 8:03:52 AM - Logged in user:  jsmith

                                                                                 ------------------------------------------------------

                                                                                  C: Local Hard Drive 

 _____________________________________________________________________________________

I should note that I had to manually re-insert the line breaks in the last example, as the line breaks were removed when I pasted the text into the Blog text editor.  I added a screenshot so you can see the true output (sans true username). 

Hope that helps somebody!

John


Comments

  • For the most part i do like the new reports. I think they would be great if this work as it did before... - dchristian 12 years ago
  • Agreed, I like the formatting in the new reports much better and the fact that I don't have to tweak column widths like I have to for the classic reports. Also, the issue I mentioned in the replication share drive space blog about aliasing column names in the new reports not working appears to have a been an older 5.3 version bug that persisted with the reports - when I tried rebuilding them from scratch the aliasing worked fine.

    And just to clarify, the appearance of the line break characters (
    ) happens in both the new and classic reports. The only issue with the new reports is that they don't process the newline characters (\r\n) properly.

    John - jverbosk 12 years ago
  • Just upgraded my K1000 to 6.0 and it appears all of the data being pulled is on a single row rather than line breaking after each return. It does not do this when I export to text file, only in Excel and PDF. Any ideas? - mprice 10 years ago
  • mprice,

    The Dell KACE engineering team is aware of the situation and we can expect a resolution in the future.

    John - jverbosk 10 years ago
    • awesome, thanks for letting us know... just noticed this issue in 6.0 and starting to look into it. - erush 10 years ago
    • I too was wondering if this was a bug (and if it was known) or not. Thanks for posting this, John! =] - awingren 10 years ago
This post is locked

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ