It names them for uniqueness and stores them away in a unique folder structure.
Consider that many large organizations that use Crystal have the same name for different reports, such as Dashboard (common naming for execs). So this might seem to be an inconvenience to a small shop, but it's really an advantage any way you look at it.
From the users standpoint they see the name you want them to, and you have a guarantee of uniqueness and open and save the report by it's known name from within CE.
Think of it as a time saving feature wherein you don't have to manage such trivial details.
You should save a copy of the reports elsewhere anyway, in which case you can keep your own name.
If the concern is that you want the Filename function, place the report name in the File->Summary Info->Title and use the Reporttitle function to retrieve it.
After working with CE for a year, and Seagate Info a couple of years before that, I still fail to see the advantage of CE's naming process. Perhaps you can explain it so my small brain can get a better grasp of what's going on.
The suggestion that "Dashboard" is a common report name raises a red flag with me. Are you saying that there might be independent development groups throughout the enterprise who would use the same name for different reports to be managed at the enterprise level, without a procedure in place to prevent that duplication?
And if the enforcement of unique naming is left to CE, what would protect each developer from having his Dashboard.rpt, alias A015/088/000/efbrsq56938cee.rpt, from being replaced by another developer's Dashboard.rpt when the second developer publishes it into the wrong folder?
And what is the reason for burying the CE version of the report so many levels deep in the Input File Store? To me, it seems like obfuscation, but I have an open mind (in spite of posts in other threads that may suggest otherwise).
I too had difficulties making the adjustment, but I now much prefer that another process, albeit programtically, manage this.
Why do you need a procedure to keep track of unique naming if there's a surefire method in place? And if the CEO wants a report called Dashboard, and the Network Manager wants one called Dashboard, why should I care that they use the same name? I do gently suggest that they further qualify it, but it doesn't really matter to me now.
As for people overwriting a report, that can happen regardless of the naming. To address your concern, I do NOT allow developers to publish reports into CE production folders, that is handled by the Crystal Administrator.
Developers push reports into Test/QA, when they're signed off, the Crystal Admin moves them into production.
I also do NOT use CE as my report repository, I use VSS, etc., as most would do for code.
A little obfuscation might be a good thing here, rather than giving the developers an opportunity to directly get at the reports in their folders, I would prefer that they use the provided tools to do so.
So red flag or no, it should provide a simpler and safer means to manage your reporting infrastructure.
It didn't sit well with my command line origin (Unix and DOS), but I find it oddly comforting now.
Hi,
I'll weigh in on Synapse's side :
The unusual method CE uses for storage of the report objects is apparently why it is so efficient at retreiving them when needed - it is not designed for 'human' ease but for system ease..
The file names it creates are irrelevant since the file name assigned by CE is never referenced by the users or developers, so who cares?
The user can be shown the Title as the original file name, or the Title or Description entered into the Summary info when designing ( or entered on the properties page when published)
Check out it's file structure sometime, yet people don't complain that they can't get at the files directly as it's designed to manage the process for you, as is CE.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.