Date Time suffix for file names

Toad Data Point
1

Dear All,

Greetings.

I am currently using TDA 3.1.0 for automating report generation.

Sequence

  1. Script to File - Dump in Staging area

  2. Run VBScript to format as per requirement color coding etc.,

  3. Copy the file to OUTPUT folder by suffixing the DateTime stamp

Observations:

  1. As compared to TDA 2.6, if the source file does not exist the Schedule Job reports an error

  2. DateTime stamp that gets suffixed is not as of that day, for some reason it still picks the DateTime stamp when the Job was first run. This has been observed with jobs created fresh in TDA 3.1 as well the ones imported from TDA 2.6. Workaround followed so far is to set a DateTime variable, but honestly that is cumbersome as we have a lot of jobs. Please let me know if there is something that I have missed. I am attaching a screenshot of the 2 files that were dumped. The timestamp of the file and system are more than one hour apart. This is causing the files to be overwritten which should never happen because the idea is to have unique file name with datetime stamp.

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/36/TDA_5F00_DateTimeStampIssue.docx:550:0]

Thank you for your guidance.

Regards,

Prashant

2

Prashant,

I’m not sure I understand what #1 means. Can you please clarify? What should/was the desired behavior here?

As for #2, yes, there was a bug in 3.1 that resulted in the behavior you’re describing. We fixed it in 3.3. Can you try it to make sure it works?

Thanks,

Igor.

3

Dear Igor,

Thank you for your message.

For point 1:

How the current job is setup

  1. Script to File - Creates an Excel sheet in Staging directory (without datetime stamp)

  2. Run Program - External VBScript to manipulate the file(s)

  3. Move file - Move the modified file and suffix datetime stamp and dump into output directory for consumption.

The difference(s) that has been observed is:

While in TDA 2.6 when the Batch is executed, the source file actually does not exist in the STAGING directory. The batch triggers successfully, creates the source file, moves it to staging directory aka no source file in STAGING directory now.

The script to file job creates it.

While in TDA 3.1 when the Batch is scheduled, it fails by saying that no source file. Well I would say the source file will only be present if the script to file part of the job runs but that has not executed as yet and the job failed compilation. So the workaround that has to be done is to create a dummy file for all the Script to File jobs that we have and honestly that is cumbersome.

For Point No. 2:

It is my understanding that TDA 3.1 is bundled with TOAD DBA Suite and for TDP v 3.2 and 3.3 it is no longer bundled. So its kind of a funny situation that the licensing team says that I am not authorized to upgrade as my license key is for TOAD DBA Suite only. so not sure if I can upgrade to Version 3.3

Thank you for your time.

Regards,

Prashant

4

Oh, I get it now. Unfortunately, it was a bug in 3.1 as well - in 3.1 we checked for file existence in copy file activity. This also was addressed in 3.3.

I’ll check on the license issue you have.

Thanks,

Igor.

5

Prashant,

I’ve got this info about your licensing issue:

…with the release of Toad Oracle 11.6 we will be running a promotion where we give away a perpetual license of Toad Data Point Professional to all Toad Oracle DBA Suite and Dev Suite customers. Toad Data Point Pro will not be included in the Toad Oracle DBA Suite and Dev Suite installation bundles, but customers will be able to download the product from the support portal and the Toad for
Oracle DBA Suite and Dev Suite keys will work with Toad Data Point Pro.

So, go ahead and download TDP 3.3 from support portal. Your Toad for Oracle DBA and/or Dev Suite keys should be able to activate TDP 3.3.

Igor.

6

Dear Igor,

Thank you so much for your reply.

I will definitely have a look.

Have a nice day!

Regards,

Prashant