I cannot get our .NET tasks to work after upgrade. I get this error when I open a task or try to create a new one:

An error occured:Could not find a part of the path 'C:\Users\<user>\AppData\Local\Temp\12\q5smexg3.tmp'.

I get to the task window but the Method and parameters section is empty and I cannot compile or refresh methods.

I am on Windows 2019.

I cannot get our .NET tasks to work after upgrade. I get this error when I open a task or try to create a new one:

An error occured:Could not find a part of the path 'C:\Users\<user>\AppData\Local\Temp\12\q5smexg3.tmp'.

I get to the task window but the Method and parameters section is empty and I cannot compile or refresh methods.

I am on Windows 2019.

I can't reproduce this. Do you have access to other servers/machines where you can reproduce this on as well?
What version did you upgrade from?

You can mail screenshots to support@visualcron.com

---

Thank you for the answer.

Well technically I moved a job from a 8.5.5 server (on Win 2008R2) to a 9.1.5 (on Win2019), so it was actually an export/import from a former version.

It seems to work now but I am not entirely sure why.

I used the client on the server and after I logged off and on the problem somewhat went away. Somewhat because the problem got back if I opened the task in question (!).

I logged off and on again and created a new job with a .NET task and copied the script directly from the old installation. This worked and now I could open the problematic task without problems (?!) and that works as well now (?!!).

VisualCron is the only program running on the new host and I have made no changes in VC or the OS when working with this.

But it seems to work so thats good for now. Thank you.

Thank you for the answer.

Well technically I moved a job from a 8.5.5 server (on Win 2008R2) to a 9.1.5 (on Win2019), so it was actually an export/import from a former version.

It seems to work now but I am not entirely sure why.

I used the client on the server and after I logged off and on the problem somewhat went away. Somewhat because the problem got back if I opened the task in question (!).

I logged off and on again and created a new job with a .NET task and copied the script directly from the old installation. This worked and now I could open the problematic task without problems (?!) and that works as well now (?!!).

VisualCron is the only program running on the new host and I have made no changes in VC or the OS when working with this.

But it seems to work so thats good for now. Thank you.

Thanks for updating us. Let us know if the issue starts occurring again and we'll take a look at it.

---

Jon, I bet when you copied from the source server the job or task ids used were already in use on the target server. When the job was pasted, it resulted in incorrect internal pointers in the database that VC uses to track jobs/ids and whatever other objects are in use. I have posted about this problem in the past and asked that when pasting a job or task VC check to see if IDs are already in use first. I suspect when you closed and reopened the client some kind of internal checking is done to clean internal links and now your job and tasks work.

Did you notice a job or task on the target mysteriously went missing due to its ID being used by the copied job/task? That is what I experienced. I wrote a script to check for the existence of an ID before copying anything from one server to another so this won't happen.

I'm sorry I didn't see your post sooner.

Gary

Jon, I bet when you copied from the source server the job or task ids used were already in use on the target server. When the job was pasted, it resulted in incorrect internal pointers in the database that VC uses to track jobs/ids and whatever other objects are in use. I have posted about this problem in the past and asked that when pasting a job or task VC check to see if IDs are already in use first. I suspect when you closed and reopened the client some kind of internal checking is done to clean internal links and now your job and tasks work.

Did you notice a job or task on the target mysteriously went missing due to its ID being used by the copied job/task? That is what I experienced. I wrote a script to check for the existence of an ID before copying anything from one server to another so this won't happen.

I'm sorry I didn't see your post sooner.

Gary

Thanks for providing your input Gary,
You mean that if you had the job/task previously copied from the same server, and then you copy it again, it will overwrite the first one because they will have the same ID yes?

It is almost impossible that a task/job would have the same ID initially, when you perform a copy of another task/job to a server

---

I don't know about copied initially from the same server, but we had this issue when we copied jobs created on a test server to our prod server. We finally figured out the existing jobid on prod was being overwritten and that job was effectively gone. When I imported from the backup, the job I had copied from test was then gone! That's when I requested a change that for a copy of a job VC check for the existence of the jobid (or task ids) and warn if already in use or default to giving a new id to avoid this problem altogether.

In the meantime I created a job that I run if I have to move a job where I get the job or and taskids from test and search for them on prod before copying. If they exist then we have to create the job or task on prod instead of copying. A pain for sure but jobs have been whacked.

I have reported on this in the past and requested changes on this should you care to get more details from my past posts.

Thanks for your time.

Interestingly, I noticed this note in the version 9.3 beta release notes:

[BUGFIX] Client: Job dragndrop between Servers->Handled deleted Connection issue (VC-1463)

When was job drag and drop between servers added? I am very interested in this feature! Does it assign new job/task id's on the drop? What about clone, does that work from one server to another as well?

Hi Gary

We have 400+ jobs, so I really doesn't hope one is missing - it will be a terrible job to find out.

Support: Why can't we get at least read acceess to the database?