WIndows 3000 and Report Builder Server 7.04
I'm hoping that you can help.
We are attempting to setup Report Builder server to run under Windows 2003.
We've added our ISAPI DLL to the Web Service Extensions and updated the
permissions (IUSR-) on the virtual directory where the ISAPI
DLL exists.
Here is the issue, when we attempt to setup the report.ini (in the same
directory as the ISAPI DLL) the dll does not seem to be reading the ini
file. We see the standard three frames come up with 'page not found' in
each when a report is requested. When we right clicking in a frame it shows
the root path/. The CacheDirectory property of the component had a
value in it and that value was used as the cache directory. The report
files were created in that directory. If we hard code the information
(CacheDirectory, WebCachePath, WebModuleURI) in the component, the report
comes up correctly. Looking at the cache directory under the ISAPI DLL
directory, the correct {GUID} directory is created when the component is
hard coded.
The ini fie worked correctly running under windows 2000 server and RB 7.04.
We simply copied the same exact directory structure over, installed the
Report Builder Server and setup IIS as described above.
Any help would be greatly appreciated.
Thanks,
Bill Geoghan
We are attempting to setup Report Builder server to run under Windows 2003.
We've added our ISAPI DLL to the Web Service Extensions and updated the
permissions (IUSR-) on the virtual directory where the ISAPI
DLL exists.
Here is the issue, when we attempt to setup the report.ini (in the same
directory as the ISAPI DLL) the dll does not seem to be reading the ini
file. We see the standard three frames come up with 'page not found' in
each when a report is requested. When we right clicking in a frame it shows
the root path/. The CacheDirectory property of the component had a
value in it and that value was used as the cache directory. The report
files were created in that directory. If we hard code the information
(CacheDirectory, WebCachePath, WebModuleURI) in the component, the report
comes up correctly. Looking at the cache directory under the ISAPI DLL
directory, the correct {GUID} directory is created when the component is
hard coded.
The ini fie worked correctly running under windows 2000 server and RB 7.04.
We simply copied the same exact directory structure over, installed the
Report Builder Server and setup IIS as described above.
Any help would be greatly appreciated.
Thanks,
Bill Geoghan
This discussion has been closed.
Comments
Check that
a. TrsWebTier.IniSettings.Enabled is True
b. TrsWebTier.IniSettings.FileName is valid, the default is
($Application)|\rbWebTier.ini
--
Nard Moseley
Digital Metaphors Corporation
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
TrsWebTier.IniSettings.FileName is valid.
Just to clarify for me.
1. For the Windows 2000 server, if you change the rbWebTier.ini file, are
the new values used?
2. For the Windows 2003 server, if you hard code the WebTier properties with
the same values you are trying to store in the rbWebTier.ini, then it works
properly?
We do not have currently have a Windows 2003 here, but if the access rights
are sufficient, I would think that the WebTier application should be able to
read the values from the .ini file.
--
Nard Moseley
Digital Metaphors Corporation
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
That is correct. The pathing is identical between the two machaines
(d:\Ameritrack\Report Server\Web Tier). The Windows 2000 server functions
correctly.
with
works
That is correct.
rights
to
During our first attempt we had the CacheDirectory property set to a
directory. The ISAPI DLL server usied that directory. It created the
directory and the required files in that directory. If the directory and
the files can be created in an entirely new path, it would not seem to be a
access rights issue.
I did some further testing and determined that it may be an issue with the
$Application. When I hard code the ini path (e.g. (D:\Ameritrack\Report
Server\Web Tier\report.ini) and clear the other pathing properties, it
works correctly. When I substitute the ini path with the $Application (e.g.
($Application)\report.ini) the report does not work correctly. Just the 3
frames are displayed as described before.
Thanks,
Bill
The TrsIniSettings class uses TppFileUtils to resolve the directory path.
Example:
uses
ppFileUtils;
if IsLibrary then
lsDirectoryPath := TppFileUtils.GetLibraryFilePath
else
lsDirectoryPath := TppFileUtils.GetApplicationFilePath;
For an ISAPI dll the Delphi global IsLibrary variable should return true.
Check out the code in RBuilder\Source\ppFileUtils.pas. You might try adding
some code to your ISAPI dll to execute the above code and write the result
out to a .txt file so that you can see the value it is resolving to.
--
Nard Moseley
Digital Metaphors Corporation
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
\\?\D:\Ameritrack\Report Server\Web Tier\
under windows 2003.
Thanks,
Bill
resolving to
\\?\C:\rbWebPub\
I copied the ppFileUtils.pas to my project folder and modified the
TppFileUtils.GetLibraryFilePath to remove the '\\?\' string, but things
still aren't quite right.
When does the TrsWebTier load the IniSettings? Can we start with
IniSettings.Enabled false, force the IniSettings.Filename to the right path,
then Load? Is there another way to assign TrsWebTier properties at runtime?
--
Thanks,
Jay Schiappa
Occusoft Corp.
The information stored in the rbWebTier.ini is read when the WebTier.Loaded
method executes. The Delphi streaming system calls TComponent.Loaded, "The
streaming system calls this method after it loads the component's form from
a stream (i.e. the dfm)."See the Delphi online help for more details.
The Form.OnCreate event fires after the Loaded method for the components.
The WebTier.OnCreate event occurs just before the WebTier loads the
information from the ini file.
--
Nard Moseley
Digital Metaphors Corporation
http://www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com