Generating HTML report on stored procs
Brian Donahue
Posts: 6,590 Bronze 1
Hello Kevin,
I don't see why the number of database objects should prevent a report
from being generated, provided you've got lots and lots of virtual memory.
The dataset that the software produces for the HTML report is in XML format,
which is usually pretty large due to the fact that it's all plain text. This
gets transformed to HTML by being filtered through the XSL template (Usually
Default.xsl).
The engine responsible for this is a Microsoft component, msxml3.dll.
With large amounts of data, msxml3 has a known performance issue. One of the
solutions is to break the XML data into smaller chunks in the software.
Another is to optimise the XSL template. Because I'm not in a position to
experiment with the former, I tried some things on the latter.
I have a very large database with 1400 objects to test with. I was
unable to get an HTML report to display, even after some hours. I did,
however get it to work eventually using the attached file as an XSL
template. What I did was to replace a reference to the data. Where
default.xsl has \root... I replaced it with "
oot". The second backslash
is redundant, and according to some MSDN articles, it causes some extra
processing to take place that involves searches up the data tree.
So try copying this file into your c:program files
ed gate sql bundle
folder and see if it helps at all.
Regards,
-Brian Donahue
"Kevin Jackson" <kjackson@powerwayinc.com> wrote in message
news:0rRAHMcBDHA.2636@server53...
> I attempted to generate an HTML report of 1100 stored procs. The bar went
> clear across the screen and then when it looked as if it was done, the app
> stopped responding, the hard drive was no longer being hit, and the
process
> was taking from 70 to 90% CPU time.
>
> I'm letting it continue to run hoping it finishes out. Should I expect
this
> report be possible on 1100 stored procs?????
>
> Kevin Jackson
> Evaluating status
>
>
I don't see why the number of database objects should prevent a report
from being generated, provided you've got lots and lots of virtual memory.
The dataset that the software produces for the HTML report is in XML format,
which is usually pretty large due to the fact that it's all plain text. This
gets transformed to HTML by being filtered through the XSL template (Usually
Default.xsl).
The engine responsible for this is a Microsoft component, msxml3.dll.
With large amounts of data, msxml3 has a known performance issue. One of the
solutions is to break the XML data into smaller chunks in the software.
Another is to optimise the XSL template. Because I'm not in a position to
experiment with the former, I tried some things on the latter.
I have a very large database with 1400 objects to test with. I was
unable to get an HTML report to display, even after some hours. I did,
however get it to work eventually using the attached file as an XSL
template. What I did was to replace a reference to the data. Where
default.xsl has \root... I replaced it with "
oot". The second backslash
is redundant, and according to some MSDN articles, it causes some extra
processing to take place that involves searches up the data tree.
So try copying this file into your c:program files
ed gate sql bundle
folder and see if it helps at all.
Regards,
-Brian Donahue
"Kevin Jackson" <kjackson@powerwayinc.com> wrote in message
news:0rRAHMcBDHA.2636@server53...
> I attempted to generate an HTML report of 1100 stored procs. The bar went
> clear across the screen and then when it looked as if it was done, the app
> stopped responding, the hard drive was no longer being hit, and the
process
> was taking from 70 to 90% CPU time.
>
> I'm letting it continue to run hoping it finishes out. Should I expect
this
> report be possible on 1100 stored procs?????
>
> Kevin Jackson
> Evaluating status
>
>
This discussion has been closed.
