Button on DCR

I have written an ipl which executes very well from the command prompt.This ipl creates some files .

To run that ipl I have added a button on my DCRs , using callserver I execute that ipl onclick of that button.But the problem arises now, when the user clicks on that button only so some files are executed and the rest are not.

What can be the reason?

I am working on TS 6.5 ,windows 2003 .

Thanks in Advance
Smiley Happy

Find more posts tagged with

Comments

nipper

You provide no information that is useful in debugging this.

From the symptoms you document it looks like a permissions issue. You will need some debugging code in your call server to see what is failing.

wild123

You provide no information that is useful in debugging this.

From the symptoms you document it looks like a permissions issue. You will need some debugging code in your call server to see what is failing.

The issue was arising because of logging that I had provided for debugging.

wild123

The issue was arising because of logging that I had provided for debugging.

So I removed all the debuggers and it started creating some more files,but not all.

When I run this script from Command prompt or as inline call from dct(give as inline in a datacapture.cfg and click on New form entry for that datatype). It executes very well giving the desired results.

But when executed from a callserver in a js , it doesnt give the desired result. and only less than half the files are created.

I have attached the code of the ipl as txt here.

Please suggest a solution!!!

nipper

1st put some debug statements in the IPL and dump to a file. See if it is trying to open all the files you expect, but failing, or if it only sees a fraction for some reason.

Adam Stoller

I have attached the code of the ipl as txt here.

Please suggest a solution!!!

Since we didn't see how you added debugging, we cannot comment on why your additional debugging broke things. Ergo - you still need debugging statements (but they should be directed into an explicitly path-referenced log file not STDOUT or STDERR) - any place in your code where you call 'die' you should change it into a call to something like 'mydie(...)' where the subroutine will first log the message to your debugging file and then call the actual die command.

I'd also strongly recommend that you give up on windows path-separators and use forward slashes - it will make your code easier to read and generally easier to maintain (one missed backslash in a double-backslash'd string can take quite a long time to hunt down as being the source of an error)

You should also learn how to create and use subroutines more so that you don't have code statements nested 8+ levels deep in code that cannot conform to an 80-character-wide screen / page.

Once you can identify where / when your code stops doing the right thing, you can remove some debugging statements and add others in a more focused location to discover what distinction in data or environment you were overlooking that caused the code to work in some circumstances but not others.