Lol, I think that was his birthday. When he died, they didn't have him in a casket, he was propped up in a lifelike pose and there were 2 straight weeks of second lines.
I don't know if it was confused by the file extension being ps1 because this is a literal embedded in a Powershell script or what, but today it has been doing so many bad suggestions, I just got tired of it.
So yes, it is hell. But better than me going and figuring out how I can standardize logo usage on PowerBI and Tableau dashboards across multiple OEMs automatically in our build process when partners can't be relied on to keep a file at a URL reliably...
And even if every OEM is supposed to have this function, I try to make things as robust as possible in the face of unexpected shit because error messages in SSRS aren't the easiest to figure out.
The synonyms actually are newish. They came in because one of the OEMs wanted to rename databases after our product was installed - which meant going into views and this function and changing each one to point to the new database. With the synonyms, everything is in one place.
Or they are super powerful and you have to do them over and over in every dashboard and on each platform because nothing is the same between Tableau and PowerBI and some logic is impossible to push into the database if it's layered at aggregate level.
Lol, I was just thinking how this would change if we retired our SSRS reports in favor of porting them to PowerBI and Tableau and I don't think anything would be able to be changed, because those platforms are just as weak for getting things done.
I'm not 100% sure why our test databases for that OEM don't stub it out, but they didn't, so I was kind of hesitant to stub it out on this test run just to get all the tests to pass.
It's a URL they are supposed to provide based on the parameters we send so that people viewing the report can go to some other place in their system that we don't control.
No even probably an issue at clients anyway, since if they did see it and it didn't fix itself, you could just patch it up by putting a function they maybe should have in their own database anyway.
This probably points to the need for more test setups that cover that configuration variation... I think it's only used in 3 reports, but, so seems crazy to test 5000 things both ways when only those 3 need to be tested each way.
There are no significant changes in this release, but one of the test environments was rebuilt (the SQL Server 2019 one), and the behavior seems messed up only on one OEM target in that environment, but I think it could just be due to timing because of this execution plan thing going on.
@PeterVandivier It's a product that works with different OEM databases. The synonym is not currently being created if the function is not on the other side (I can change that if I want - you can create an invalid synonym).
I'll revisit after all the test suites are run. But what I had done with sp_recompile on the function and then call it with OPTION(RECOMPILE) and it fails every time, not just the first time.
Is there a reliable way to make a function that checks if a synonym exists and then calls the synonym function in the other database through the synonym, but if the synonym does not exist, return NULL or call some other function? What I'm seeing is that the first call gives an error, but then subsequent calls don't - like it makes a plan and finds that the synonym in the IF doesn't exist, but then uses the plan and doesn't hit that branch on subsequent calls.
Also, I am waiting on a big computed column adjustment on a table in another system. The first one took 6 hours. I think that might not have been the best design.