I have a problem in a small SSIS package that I'm trying to do for storing a query result into an excel file
I want the file to have a dynamic name of Missing_Timecards_#DATETIME#.xlsx
for example: "Missing_Timecards_20220808_131321.xlsx"
for this I have created a template file that has the columns and sheet name I want.
and I have set a system task to copy this template file into a new one with the dynamic name I want to have:
for the variables I have set a combination of a few fields to get my dynamic filename with the date:
the expression for getting the date is
REPLACE(REPLACE( REPLACE(SUBSTRING((DT_WSTR,50)GETDATE(),1,19),"-",""),":","")," ","_")
so far so good, no errors here, when the process starts the variable gets calculated, the filetask creates a copy with the freshly calculated field and goes to the dataflow that retrieves the data and saves it into the excel file path set with the variable that was calculated originally for the filename+datetime
However here is where the issue appears, it seems that the variable is calculated again, so a new file gets created with a "fresh" datetime part of the name, and as the sheet name doesn't match it gives an error.
I think the issue is that is calculating the variable again, how do I stop this from happening? (I have set delay validation = true in for the excel connection and the dataFlow)
As you've identified, GETDATE() is calculated each time it is evaluated. Instead, I favor using a System scoped variable like #[System::StartTime] as it is the time the package started execution but remains constant for the duration of the package.
Literally, swap reference to getdate() with #[System::StartTime] and you're set.
The other option is to
Copy the existing expression to your clipboard
Clear the expression from the Variable
Add an Expression Task to the Control Flow and re-use the expression in the clipboard to assign the value to your #[User::DateTime] variable
Personally, I favor the former approach as a consultant because I still run into SQL Server 2008/R2 packages and the Expression Task was not available for the product.
Related
i want to read first line of the flat-file containing date value and compare with a user variable defined in 2008 SSIS package without using sript task.
This solution is a bit long for what the simple task you require but since you don't you want to use script task, you can try below:
Create variable to store the date value from your flat file
Create a data flow task to import the flat file into a SQL table.
Add an Execute SQL task to get the first line from the SQL table and map the result
set to the variable created at step 1.
You can now compare the variable created and the one you already have.
e.g #[User::NewVariableCreated] == #[User::ExistingVariable]
This will return a Boolean data type result of True or False depending on the values supplied.
Hope this helps.
One option is to use a Conditional Split. Within this task, a condition can then be added comparing the date column of each row with the variable. A basic example of a condition for this is below, which checks to see if the date column of each row is equivalent to or more recent than the date variable. From here, the rows be directed based off whichever condition they match.
FlatFileDateColumn >= #[User::DateVariable]
Good Day All,
I have a select query where i pull the data from sql ie
select invno , date_received from sales
What i want to do is split the file into multiple files using conditional split.
I don't know how to set the condition i tried as below
But it just creates one file, how do i create the multiple files based on column value if i don't know what the column value would be?
Also i would like to assign the column value ie INVNO to filename as well to prevent overwriting of files
Using the out of of the box componentry, your best bet would be to have something like this
The Execute SQL Task will return a Full Result Set to an SSIS variable of type Object. Your query would generate the distinct set of INVNO. SELECT DISTINCT T.INVNO FROM dbo.Sales AS T;
The Foreach Loop Container is then going to "shred" that recordset into a single instance of our INVNO. This requires you to have a variable, probably of type String, to receive that number.
The Data Flow Task will have as the source query a parameterized query. Assume OLE DB Connection manager, that'd be select INVNO, date_received FROM dbo.Sales AS S WHERE S.INVNO = ?; and then you map in the current value of INVNO (assigned as part of the shredding from the FELC)
Finally, the Flat File Connection Manager will have an Expression on the ConnectionString property that factors in the full path to the output file. It could be something as simple as "C:\ssisdata\" + #[User::Invno] + ".csv"
Oh, and set DelayValidation = True for the Flat File Connection Manager and the Data Flow Task.
I have been working on a requirement which serves the following:
Fetching record set from an OLEDB source through an execute SQL task.
These record set is then formatted into fixed width and merged into a single column with the help of another Execute SQL task.
The formatted data is then exported to a flat file..
Now, the requirement has been changed to have the record set (Originally coming from OLEDB source) exported to three separate flat files (Each with different set of data) depending upon value of a package variable.
e.g If (USER::Instructor = 'DEV') then 5 fields will be extracted to one flat file.
e.g If (USER::Instructor = 'Jerry') then 7 fields will be extracted to another flat file. And so on..
My current challenge is I have to extract different set of data without using expressions in the precedence constraint.
You will need a different data flow task for file formats that you want to be able to export. So a different task for the 5 field export to the 7 field export.
In the Control Flow, you can choose which of these data flow tasks gets executed based on the value of your package variable.
For example, if you set the Disabled property of the 5 field data flow task to the expression #[USER::Instructor] != 'DEV' , then it would be disabled whenever the instructor was not Dev, and enabled whenever it was dev.
I have a pretty simple package. It reads a flat file, extracts date from a header record and subsequently uses derived column component to reformat data to the desired output format. One of the columns (FileRunDate, string, length 8) in the derived component is defined as a string and in the expression I'm assigning it to a variable I set earlier in the script component - #[User::vRunTimeDate]. When the process runs, the output file gets generated, however FileRunDate is blank. The default value of the variable is blank, however if I were to set it to some date, then the output file does reflect this value. It seems that the variable assignment in the script task does not work, but if I were to debug it, then I see how the value is being set. The variable has an attribute of ReadWrite.
Any feedback is greatly appriciated.
I currently work in an environment where reports must be emailed to users as a PowerSoft file.
There is a global PowerBuilder function which is used on a computed column my datawindow. This datawindow becomes the final psr report.
In my testing the function is resolved fine, when run live. However, when the user runs the report, it sends the psr to their respective email address. (I didn't design the system)
When they open the psr, the function is not resolved.
Does anyone know if it is possible to wrap this function into the datawindow or into the final psr?
Thanks,
Glenn
The global function must be available through the PSR viewer. Period. The users' PSR viewer must have that same global function in order for the datawindow to render correctly.
There is a way to work around it, but it's rather tedious. Basically, you need to replace your computed field (that uses the global function) with a SQL column. Update your SQL to include a dummy column of the appropriate datatype. When you finish retrieving, get the value of your computed field (Look up "Describe ('evaluate')") and do a SetItem() on your dummy column. Display the column instead of the computed field.