Work Ethic

People have different work ethics.

Let's say a company had a position.  Your job responsibilities included doing absolutely nothing for 40 hours a week.  Good pay, good benefits, good retirement., good job title.  You're hired.

I think some people would absolutely love that role.  And they would watch the clock, head out at 5pm on the nose.  Live for the weekend.  And return reluctantly on Monday, do it all over again.  That's our 9-5er.

Let's say you had a position with no job specifications.  Other than to be creative.  They provide you any tools you need.  Unlimited capital, products and public information.  At the end of a year, we'll see what you come up with.  Research and development.

I think that person would show up early to work, stay late, all night perhaps.  I don't think money would be the driving factor.  Nor the titles.

I don't think these jobs exist.  Well maybe.

I think the creator of the Java programming language was given a similar role back in the 1990's at Sun Microsystems.  And he produced a working language that's been around for quite a while, even duplicated by another language with similar syntax.  Original thinking, creative thinking, no pressure.

At one job long ago, they had a programmer on staff, 1 person.  I never saw him working on a project so I asked why.  Said the company was trying to be acquired and it would look better if they had a programmer on staff for potential buyers.  Cool.

I worked at a place where over 50 people worked on a project for many years.  Some outside consultants viewed the quality of the work.  The entire project was shelved and never spoken of again.  And they purchased on off the shelf product and their people customized it to the tee.  Then the department got a make over, all new people.  I showed up late to that party, but I heard there was a lot of overtime offered and people worked every weekend.  Let's earn as much as we can with no results, right?

Seems to me, there's a segment of people that cross the t's and dot the i's to ensure they did their required job function as expected.  But don't expect much more.  What I like are the time bombs at the end of a project.  People sit on problems, wait until an the opportune moment to send up their concerns.  We're about to move the to QA.  Raises hand.  I thought I'd mention these 12 issues.  Why didn't you say something earlier.  Shrugs shoulders.  Project delayed.  Team player, right?

What about hiding the business rules.  That's a good one.  Keep all the information secure within the perimeter of your head.  Ensures job stability, increases status and slowly release info, but never document it.  That's good work ethic, right?

How about the mystery changes.  This program worked flawlessly forever.  Now it stopped working.  What changed?  And we plunge into super-troubleshooting mode for hours and hours not knowing which configuration changed from the thousands of settings.  Oh look, it started working again.  Process repeats from time to time.  Keep 'em on their toes, right?

They say when you're rowing in a boat, make sure the others are rowing along with you, and not creating holes in the bottom of the boat.  Any truth to that?


Resolving Dts.Variables in Script Component of SSIS to call REST API

For a project, I was tasked with making a REST API call to send up some data using JSON, then receive the returned values and place into a SQL Server table.
So started out using a Script component.  And pieced together some code, to get the REST API call to work successfully.  In order to do that I first had to figure out the correct syntax.  I used the built in plug-in using Chrome.
Click the Launch button and another window appears:
After entering the URL for the REST API, I selected POST.
Then tweaked the JSON data until it processed success. So the REST API call was accessible.
Next, went into SSIS using Visual Studio 2015, added some code, including a Script component.  Then pieced together some code to send a JSON statement to the service using a hard coded JSON string.  And that worked.
Next, had to feed data into the Script component, using an Execute SQL script.
Next, added a For Each Loop component and set the result set to a variable: User:ResultSet
Then created 4 User variable to hold the contents of the result set.
Then within the For Each container, added a Script component, selecting "Source", not "Destination" nor "Transformation".  And attached a Destination table in SQL Server.
Then you set the Output expected Returned values within the Script component.
Then edit the script.
I got it to run success when hard coding the JSON string.  Of course we have to then set the thing to run using real data, flowing in from our Source data from our Execute SQL component. 
So we set our "ReadOnly" variables, not "Read/Write", added the 4 User variables and head back to the Edit Script again.
And in the code, we swap out our hard coded JSON statement with a well defined code substitution our 4 User:Variables.
But we ran into an issue.  It wasn't able to read our variables.
Error CS0234 The type or namespace name 'Variables' does not exist in the namespace 'Microsoft.SqlServer.Dts' (are you missing an assembly reference?)

I read some post online that suggested many possible solutions, none worked.  Then I remembered that you have to add the Microsoft.SQLServer.ManagedDTS.dll to the project, which I did, still threw an error.
Then searched in a few places, and created a Matrix, comparing the DLL values from the SQL Server 2016 box to the development box that has Visual Studio 2015:
You can see that the DLL could reside in multiple places, specifically the SDK directory and the GAC.  The 592 and 593 were the file sizes to I could identify the differences.
It turns out, the version in the GAC needs a different version so I overwrote it with a newer version.
Reopened Visual Studio:
string strStreet = this.Variables.street.ToString();

I changed the syntax slightly, and it resolved correctly and was able to flow a record through and it showed up in the database table as expected. 
So I opened up the SQL statement and removed the "top 1" and it ran entire way through without errors.
So it seems that the dll version must have corrected the issue, as well as having to change the syntax slightly for from:
That's my story and I'm sticking to it.