Technical Questions
 Crystal Reports Forum : Crystal Reports 9 through 2020 : Technical Questions
Message Icon Topic: Errors when moving report from development environ Post Reply Post New Topic
Author Message
Dreaming
Newbie
Newbie
Avatar

Joined: 26 Jan 2010
Location: Canada
Online Status: Offline
Posts: 17
Quote Dreaming Replybullet Topic: Errors when moving report from development environ
    Posted: 19 Feb 2010 at 8:30am
Hi,

I'm new to CR and I have no background developing for it, but I've recently created a report with some fairly intricate expressions on-board.  The report runs smooth as glass in my development environment, but breaks once I move it out to production clients. 

I thought at first that it had to do with improperly mapping to the correct database, but I tested this by moving working reports from the production side, back into development, and they ran without a hiccup.  It seems both spheres are contacting the same database.  I have no background in server admin so I'm not going to try to figure that out.  Regardless, reports that do nothing more than display fields can be moved back and forth between development and production seamlessly.  Mine, however, cannot.

This is the error code I get when running the report on a client:

Error:515 Error in formula <French_File_Name>
Execute <PEStartPrintJob>
Contact your system administrator for assistance.

Make sure that you have an ODBC data source called DATA_BASE configured on your machine and you can access database DATABASE001 on server SERVER01.



The formula named in the error is this:

LOCAL StringVar Array SplitFileName;

IF INSTR({COM_VOLUME_LABEL_VIEW.pd_file_name},"|") = 0 THEN
  TOTEXT(TRIM({COM_VOLUME_LABEL_VIEW.pd_file_name}))
ELSE
  (
  SplitFileName := SPLIT({COM_VOLUME_LABEL_VIEW.pd_file_name},"|");
  TOTEXT(TRIM(SplitFileName[2]))
  );


It's pretty simple really since the bulk of the coding takes place in another formula altogether, but this is the one that's being cited.  One thing to note is that even when this field is removed, the same error will pop up with another expression, elsewhere in the report.

Again, these expressions work perfectly in development so there's nothing wrong with syntax or logic.  I've read that sometimes .dlls need to be distributed with CR reports, but I have no idea how to go about doing this.  I have no tools to allow me to monkey with .dlls and I don't even have access directly to the database.  All I have available to me is CR 8.5 and I'm not a programmer.

Suggestions are appreciated, although just understanding what might be wrong would be a big step.

Thanks.


Edited by Dreaming - 19 Feb 2010 at 9:04am
IP IP Logged
Dreaming
Newbie
Newbie
Avatar

Joined: 26 Jan 2010
Location: Canada
Online Status: Offline
Posts: 17
Quote Dreaming Replybullet Posted: 19 Feb 2010 at 12:19pm
As a test, I moved this formula to one of the working reports in production, which caused it bug out in just the same way as the one I'm trying to deploy:

LOCAL StringVar Array SplitFileName;

IF INSTR({COM_VOLUME_LABEL_VIEW.pd_file_name},"|") = 0 THEN
  TOTEXT(TRIM({COM_VOLUME_LABEL_VIEW.pd_file_name}))
ELSE
  (
  SplitFileName := SPLIT({COM_VOLUME_LABEL_VIEW.pd_file_name},"|");
  TOTEXT(TRIM(SplitFileName[2]))
  );

The field and table names are identical between the two, so there's something in the code that's causing the report to vomit.  I even simplified it down even further and managed to get the following formula through without a hitch:

TOTEXT(TRIM({COM_VOLUME_LABEL_VIEW.pd_file_name}));

So what the heck is wrong with the other one?  Again, the first formula has been tested repeatedly and works perfectly fine until the report is moved client-side.

I should mention that the reports that do work have no formulas in them.  They're just straight up field displays.  The only one that does have a formula is the one I tested above where the simple TOTEXT(TRIM()) works, but the more complex formula fails with an Error:515.
IP IP Logged
Dreaming
Newbie
Newbie
Avatar

Joined: 26 Jan 2010
Location: Canada
Online Status: Offline
Posts: 17
Quote Dreaming Replybullet Posted: 23 Feb 2010 at 7:44am
No ideas at all?
IP IP Logged
kevlray
Admin Group
Admin Group
Avatar

Joined: 29 Oct 2009
Online Status: Offline
Posts: 1587
Quote kevlray Replybullet Posted: 23 Feb 2010 at 7:59am
For what it is worth, the code looks correct.  CR 8.5 is considered pretty ancient.  I do not know if there are any 'differences' in the DB's from development to production (version differences?).  But still you would think that the formula should still work (I hate error numbers without explanation).
 
Lots of luck.
IP IP Logged
kevlray
Admin Group
Admin Group
Avatar

Joined: 29 Oct 2009
Online Status: Offline
Posts: 1587
Quote kevlray Replybullet Posted: 23 Feb 2010 at 8:15am
I was just noticing something.  Is it possible that {COM_VOLUME_LABEL_VIEW.pd_file_name} would be NULL.  If so, this could cause the formula to fail in production.
IP IP Logged
Dreaming
Newbie
Newbie
Avatar

Joined: 26 Jan 2010
Location: Canada
Online Status: Offline
Posts: 17
Quote Dreaming Replybullet Posted: 23 Feb 2010 at 8:57am
Hmm.  I know that {COM_VOLUME_LABEL_VIEW.pd_file_name} won't ever be null, but I wonder if this might occur if the second part of the split, following the "|", might be.  I guess that if I was trying to call a split(),[2] where that value was null, it might have a problem.  I don't think that field can have a value configured in such a way, but I'll review it shortly.

Thanks for taking a look at it.

BTW, I'm using 8.5 because it's integrated in our IM package so it isn't even upgradeable.  If I'd had 9.0+ available, it would have saved me about two weeks of tinkering already.  Out-of-date software can be such a headache.
IP IP Logged
Dreaming
Newbie
Newbie
Avatar

Joined: 26 Jan 2010
Location: Canada
Online Status: Offline
Posts: 17
Quote Dreaming Replybullet Posted: 23 Feb 2010 at 1:06pm
Well, the data seems OK, but I just noticed something else that might be important.  This error is occurring before I can select a record to display in the form.  As soon as the report is run, I should be prompted for a bar code, but the error occurs prior to this.  Something is making it bug out before any processing is actually being done.

I've double checked the SQL statement (which is basically identical to the forms that are working) and could find nothing amiss.  I've even stripped out the parameter field I was using and replaced it to see if there might be something there, but no dice. 

Here's the SQL SELECT statement anyway, for reference.  If the report is bugging before I'm prompted for a parameter, I'm guessing that whatever it is must be found here.  It looks clean to me though.

SELECT
    COM_VOLUME_LABEL_VIEW."pd_file_no",
COM_VOLUME_LABEL_VIEW."pd_part_no", COM_VOLUME_LABEL_VIEW."pd_popen_date", COM_VOLUME_LABEL_VIEW."to_date", COM_VOLUME_LABEL_VIEW."pd_file_name",
    PD_BARCODE."PD_BARCODE",
    CAST(SUBSTRING(
COM_VOLUME_LABEL_VIEW."pd_title", 1, 250) as varChar(250)),
    CAST(SUBSTRING(
COM_VOLUME_LABEL_VIEW."pd_title", 251, 250) as varChar(250)),
    CAST(SUBSTRING(
COM_VOLUME_LABEL_VIEW."pd_title", 501, 250) as varChar(250)),
    CAST(SUBSTRING(
COM_VOLUME_LABEL_VIEW."pd_title", 751, 250) as varChar(250))
FROM
    { oj "D000"."DOCSADMIN"."
COM_VOLUME_LABEL_VIEW" COM_VOLUME_LABEL_VIEW INNER JOIN "D000"."D000"."PD_BARCODE" PD_BARCODE ON
       
COM_VOLUME_LABEL_VIEW."pd_pttobcode_link" = PD_BARCODE."SYSTEM_ID"} 
WHERE
    PD_BARCODE."PD_BARCODE" = 'A051237296'


The only thing that doesn't make much sense to me is how the last line keeps the absolute value that was previously used instead of showing {?Barcode} like I'd expect.  From what I've read, the parameter name should be shown here and not the absolute value.

Beyond this, I'm pretty much at a loss.
IP IP Logged
Post Reply Post New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum



This page was generated in 0.062 seconds.