Sorry for the long post; the following is a distillation of a thread from another support forum where no one could come up with an answer. Hopefully, someone here can help.
Using CR 9 and VFP 7, my application has a number of reports that incorporate a “logoheader.rpt” file as a subreport in the report header band. The idea being that the end users can change the appearance of their logo and company name information simply by editing this “logoheader” report file. All main reports have the “Re-import When Opening” checkbox checked for this header subreport. Unfortunately, the whole scenario fails at customer sites because the location of the embedded subreport is stored as a hard-coded UNC path from my development machine, complete with machine name!
I have code that loops through the
<report object>.Database.Tables.ConnectionProperties
collection and changes the source data table path names--for essentially the same reason. Surely there must be a public property of the subreport object that stores this physical location path name that can be reset on the fly in the same manner, but, so far, my search through the object model documentation comes up cold. Can anyone help me out here?
On my development machine if I do this (update the LOGOHEADER.RPT file) and then run one of the main reports that uses it as a subreport header, all is well, the logo revisions show up just fine. Of course on my machine the hard-coded path is not an issue because it remains the same.
At the customer site they do the same, and then run the main report and the old logo header info is still there, the revisions are being ignored, meaning it is still referencing the embedded subreport even though the "Re-Import When Opening" checkbox is checked. If they then use their RDC license to edit the main report and manually attempt the Re-import task, they get an error message displaying the original hard-coded path from MY machine and saying the subreport file cannot be located. They are then forced to delete the subreport and re-insert it from the file location on their machine. Not good, to put it mildly.
When I programmatically call the ReImportSubreport method, it does the same thing, so the results will be the same--works here, not at customer site. I tried calling the Section.DeleteObject method followed by a Section.AddSubreportObject method, but then I get a message that it requires licensing. Meaning I can only use that technique at customer sites where every single machine has an RDC runtime license, at $199 per pop. Again, not good.
The LOGOHEADER.RPT is in the same folder as the main report, and the directory structure is the same from APP\CRYSTAL\REPORTS down. It's only above that (MYMACHINE\\CDRIVE\\PROJECTS, etc., etc.) that it differs. So if the folks at Crystal Decisions had just stored a relative path, all would work just fine.
My frustration is that the whole point of the exercise in the first place was to allow the end-user to easily modify the whole header, not just the logo graphic. This would allow them to change the size and position of the graphic, as well as fonts, font colors and other information in the header. Why would Crystal give us the ability to use subreports, the ability to force the main report to re-import the subreport each time it loads, and then muck up the entire scenario by ignoring revisions to the subreport simply because they've chosen to store a hard-coded path to it with no means of revising that at customer locations.?
Using CR 9 and VFP 7, my application has a number of reports that incorporate a “logoheader.rpt” file as a subreport in the report header band. The idea being that the end users can change the appearance of their logo and company name information simply by editing this “logoheader” report file. All main reports have the “Re-import When Opening” checkbox checked for this header subreport. Unfortunately, the whole scenario fails at customer sites because the location of the embedded subreport is stored as a hard-coded UNC path from my development machine, complete with machine name!
I have code that loops through the
<report object>.Database.Tables.ConnectionProperties
collection and changes the source data table path names--for essentially the same reason. Surely there must be a public property of the subreport object that stores this physical location path name that can be reset on the fly in the same manner, but, so far, my search through the object model documentation comes up cold. Can anyone help me out here?
On my development machine if I do this (update the LOGOHEADER.RPT file) and then run one of the main reports that uses it as a subreport header, all is well, the logo revisions show up just fine. Of course on my machine the hard-coded path is not an issue because it remains the same.
At the customer site they do the same, and then run the main report and the old logo header info is still there, the revisions are being ignored, meaning it is still referencing the embedded subreport even though the "Re-Import When Opening" checkbox is checked. If they then use their RDC license to edit the main report and manually attempt the Re-import task, they get an error message displaying the original hard-coded path from MY machine and saying the subreport file cannot be located. They are then forced to delete the subreport and re-insert it from the file location on their machine. Not good, to put it mildly.
When I programmatically call the ReImportSubreport method, it does the same thing, so the results will be the same--works here, not at customer site. I tried calling the Section.DeleteObject method followed by a Section.AddSubreportObject method, but then I get a message that it requires licensing. Meaning I can only use that technique at customer sites where every single machine has an RDC runtime license, at $199 per pop. Again, not good.
The LOGOHEADER.RPT is in the same folder as the main report, and the directory structure is the same from APP\CRYSTAL\REPORTS down. It's only above that (MYMACHINE\\CDRIVE\\PROJECTS, etc., etc.) that it differs. So if the folks at Crystal Decisions had just stored a relative path, all would work just fine.
My frustration is that the whole point of the exercise in the first place was to allow the end-user to easily modify the whole header, not just the logo graphic. This would allow them to change the size and position of the graphic, as well as fonts, font colors and other information in the header. Why would Crystal give us the ability to use subreports, the ability to force the main report to re-import the subreport each time it loads, and then muck up the entire scenario by ignoring revisions to the subreport simply because they've chosen to store a hard-coded path to it with no means of revising that at customer locations.?