Hi,

I have an execute task which uses the folowing parameter with a variable:

G:\Institutional Asset Management\PM\Indexfondsen\IW\Data publicatie\NAV FUNDS\NAV_{DATEADD(Days|12/30/1899|M/d/yyyy|{TASK(a65422c4-7a01-4534-8a68-634344de95eb,StdOut)}|yyyyMMdd)}_EEIF.csv

If I open my client, open the variable window and copy the string from above, I get the folowing error:

"[Error in SetVariables, string: G:\Institutional Asset Management\PM\Indexfondsen\IW\Data publicatie\NAV FUNDS\NAV_{DATEADD(Days|12/30/1899|M/d/yyyy|{TASK(a65422c4-7a01-4534-8a68-634344de95eb,StdOut)}|yyyyMMdd)}_EEIF.csv, err: Conversion from string "" to type 'Integer' is not valid.]"

Now I close the variable window, open it again and paste the same code in there.
I get a different result, but this is the result I expected to get:

G:\Institutional Asset Management\PM\Indexfondsen\IW\Data publicatie\NAV FUNDS\NAV_20110430_EEIF.csv

The value of the is {TASK(a65422c4-7a01-4534-8a68-634344de95eb,StdOut)}: 40663

??It looks like my task is failing due to this issue??

I can reproduce this by closing the client and reopening the client and do the steps again.

I checked my variable {TASK(a65422c4-7a01-4534-8a68-634344de95eb,StdOut)} also after closing and opening the client. The 1st time I enter this variable in the variable window it is 'empty'. If I close the variable window, open it up again and paste the variable again, the 40663 value is showing.

Regards,
Erik

---

Sorry for the late reply. I can't get this Variable combination to work at all. There seem to be something wrong in the parameters but I am not seeing it right away.

Anyway, the error indicates that output was empty the second time you looked at it.

If I use your variable as is it does not work:

G:\Institutional Asset Management\PM\Indexfondsen\IW\Data publicatie\NAV FUNDS\NAV_{DATEADD(Days|12/30/1899|M/d/yyyy|40663|yyyyMMdd)}_EEIF.csv

The value should be 40663 right?

---

Hi,

Yes, the task output variable contains 40663.

It should add 40663 days to the date 12/20/1899 to get the correct date. The 40663 number comes from an Excel cel read task which is an actual date in Excel, but it returns a number.

The 1st time I parse the line, I get an error as described in my previous post, the 2nd time I get the good date in the string.

Regards
Erik

---

There must be something specific with that date string because your string does not work here at all (I hard code your value). Too tired right now to see why.

What if you (the second time) just look in the variables browser at your output - is that empty?

---

Hi,

If I open the variable window (just after starting the client) and go to the task output of {TASK(a65422c4-7a01-4534-8a68-634344de95eb,StdOut)} it gives me 40663.

Then if I enter my code {DATEADD(Days|12/30/1899|M/d/yyyy|{TASK(a65422c4-7a01-4534-8a68-634344de95eb,StdOut)}|yyyyMMdd)} I do not receive the error anymore.

It looks to me that the there is a resolving issue here. Browsing to the task output, after restarting the client, gets the good value. If I enter my code with the date calculation aster it, it is also fine. So here the 1st time parsing the task output is ok.

If I enter the task output variable the 1st time after client restart, there is no output at all, re-paste the same code gives me the 40663.

regards
Erik

---

Hi,

It looks it has nothing to do with the DATEADD function. It has to do with task output in my case the output of the Execute task.

I have an other task wich also gives me an emtpy task output. I used the variable window to check this. The 2nd time I pass the value in there, there is a value, not the 1st time.

I saw this today because I received an error email (email task) which holds the task output in the body. The body holds more text, but there war no task output in there, but the task has several lines of output.

🤬 At this time I getting a bit frustrated. Not all the outputs are lost (luckily) but I can't trust my jobs anymore, and that is a serious problem.
Any progress in finding the error?

Regards,
Erik

---

Hi,

I tried to recreate one task to see if the newest task doesn't has this flaw, but also my newly created job behaves the same way....

Regards
Erik

---

In the newer versions we fetch variable output from server. Previously, we downloaded a part of output at logon and used that. Now, on demand, we download the data from the server. This is the major difference.

So, we have some follow up questions:

1. the Task - it does not run during the time you try to copy/paste this?
2. have you tried waiting for a longer time before pasting it in again?
3. are you having the same problem when connecting locally against this server and copy/paste?

I guess, next thing is to add some debug information to see where it goes wrong.

---

Hi,

To answer your questions:

1. The task is not running.
2. No I did not, but after trying, same result.
3. I use Remote Destop to connect and I use the local client on de VC server itself.

😒 It looks to me that the 1st time pasting a value in the variable window never shows the result. You always have to type someting after pasting it.
By typing the variable is is working fine, so looks like the event is not triggered right when pasting the value for the 1st time.

I don't know if this has anything at all to do with the error I encounter. I thought I use the variable window to check, but this might not be the best way to test it.

I'll try to test this in the latest version 5.7.4.

Regards
Erik

---

It looks to me that the 1st time pasting a value in the variable window never shows the result. You always have to type someting after pasting it.
By typing the variable is is working fine, so looks like the event is not triggered right when pasting the value for the 1st time.

In the current beta 4.7.5 this looks fixed.

I will test some in the new beta, but it is hard to reconstruct this issue. I might not succeed...

Regards,
Erik

---

Today a job failed which contained a task which gave me no taskoutput using a variable in an email task, but today there was task output there. Arrgghh...

💤 So I'm not sure if I can reproduce this...

Regards,
Erik

---