Welcome to the Lounge

The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.

Asia is a beautiful tropical paradise that has only 1 shortcoming: Asians.
too damn many of em, there's literally nowhere you can go where there aren't other people, 24/7... no empty country side, no empty mountains, no empty forests (what little remains), no such thing as an empty beach.

interestingly I watch a British series called Death in Paradise, set in a fictional Caribbean island, although Saint Marie doesn't exist it is filmed in Guadeloupe and nearby locations.

One thing stands out: a tropical countries that have done it right. Small populations, most of their islands un/low-developed, every day: get enough for the day and then enjoy life. (ok, some over simplification but mostly like that.)
Asians have burned and asphalted almost all of their jungles, built the ugliest crowded cities, and well to keep it short: every day is about money at any cost no matter how long it takes, and taking free time is seen as lost opportunity for more money.

I'm tired, I'm always tired. Everyday think about leaving, (100% no lies) and almost ready to get out, but just a little bit more have to do. (family, sigh).

I think murder victim in Death in Paradise must be one of the greatest acting job for British actors at the moment. They fly you out, you get bumped off in the first couple of scenes, then you have to sit around in a fully funded Carrbiean hotel until the rest of the episode has been shot, then they fly you home.

Like I'm A Celebrity Get Me Out Of Here, if you aware if the show. Stars get flown out to Australia, the one voted out first then has to live in the 5 star hotel for the next couple of weeks waiting for the rest of them to leave. Losing on that show is winning if you ask me.

Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.

We attempted a deployment last night. This involves both one or more web apps, and one or more databases. The web apps gave us no problems, and all but one of the databases deployed just fine.

Why the one data base failed: We have for db environments dev, test, QA, and production. We develop on dev (of course) pretty much ignore test, test on QA (external testers), and deploy to production. SQL Server versions by environment:

dev - 2012
Test - 2008R2
QA - 2016
Production - 2008R2

While developing, we used DATEFROMPARTS. This tested fine in Dev and QA, but failed on production. We spent two hours coming up with a fix, but since we couldn't run it through a proper test cycle, we had to roll back everything.

".45 ACP - because shooting twice is just silly" - JSOP, 2010-----You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010-----When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

You have simple life...
Imagine a few hundred customers... Each have one production environment and at least one test environment (some has two or three)... Each (can) have a different OS, with different patches and .NET Framework, different SQL (version and edition)... The network can contain from a one to n computers, each with different role (like printing server, SQL, app, web)... They may use NLB and clustering...

Now deploy an update to all of them...

"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012

I doubt we would be able to use it, or that it would even mitigate the problem I describved, but gimme a link.

".45 ACP - because shooting twice is just silly" - JSOP, 2010-----You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010-----When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

It's not so much luddite-ness as not having all of the servers on the same freakin version. It's madness.

".45 ACP - because shooting twice is just silly" - JSOP, 2010-----You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010-----When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

He and I both work for people who are dictated to by yet another organization. A very annoying organization which pays no attention whatsoever to the real-world issues their dictates create. I often DISAgree with their ideas, and really want to tell them to STIG it where the sun don't shine.

Without competition in inhouse development, I get off easy in a certain way.

I have a parallel set of all the main web-app pages. They live on production and differ only by a nuance in the name that distinguishes them. When a page in this set is opened it checks its own name and determines if it's targets are also live production or dev.

If and when everything works (a couple of competent testers who will also be the users for other development), the original files are archived for quick-replacement in an emergency and the dev versions are all saved to the live production names.

It already worked on production so it will work on production.

This works because, at least for quite a few years, it's all my private domain for development so there's no conflicts (human or code). Roll-backs are rare because we (myself and the testers/users) keep the attitude that this stuff has our name on it and one ought to have pride in their work (i.e., don't make a jackass out of yourself in front of 400-500 people). An error shows up in well under a minute after go-live, if there is one, with ca. 3000-4000 hit/hr for the internal site as a whole.

The web app itself was fine (although I don't know what OS version is running on the web server). It's the db servers that caused the issue.

".45 ACP - because shooting twice is just silly" - JSOP, 2010-----You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010-----When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

That's the beauty of my luck position. I am developing the item where it will run - accessing the same DB's and all.

Usually they're generic and the actual SQL is by one of those two users (DBA's) - I need to make sure connections work, interfaces work, all the usual. Makes it all beautifully transparent.

But you're in a more realistic situation - unless someone will clone the entire production system for you, frequently, there's going to be deviations developing. If it feels a bit better, you'll probably find out it's a very small thing - but you know how computers are: "almost doesn't count".

Seriously though, you might as well not test at all if your test environment is eight years more modern than your production environment...
I know it's easy to say, but your environments really should be as similar to each other as possible.
That makes it a lot easier to find environment specific bugs should they arise.
Maybe you can set your dev and QA environments in 2008R2 compatibility level[^] so at least your modern code doesn't work in those databases either even if it's supported by the engine?
I know you're in a difficult situation and such changes have to go through umpteen layers of management, but it's a thought

FYI, the compatibility setting won't help. I checked and that function works fine under sql 2014 with a db comp. setting < 110.

This is a lesson (thanks JSOP) that testing should be done in the same environment as production. Our desktop apps are compatible with 2005 (90) so any possible breaking changes always get tested against that environment. I've been bitten by the backward compatibility issue more than a few times, mostly for dumb stuff like older versions requiring any field in the order by to appear in the select.