Morning

Morning

stackoverflow.blog/2019/09/17/…

> The future has more in store. There have been efforts to build a tracker for sites other than Stack Overflow called Boson, a bot to help detect sock puppetry and other voting fraud

uh oh

heroin-bikes.com/?___store=en&___from_store=fr

^^^^ IMO a it's weird name for a bike

morning

morning

morning

morning

@McNets because it's for people who are willing to spend waaaayyy too much money to feed their cycling fix

man, it's hot in this shade 😅

@PeterVandivier may be they are looking for some sort of addicts

i get how it happens, but there's something mentally disarming confronting the idea that those bikes cost more than some cars

many cars even

my car certainly

I know, I spent more money on bicycles than on cars last years

but of course

because the perforated fork slices into the air

or I will return it once it turns out I am not fit enough to be formidable

just those words in that order and i'm already convinced you're stoned

@McNets do you happen to use Strava?

@dezso No, no apps

BTW, my last bike is in fact an e-Bike (I'm getting older)

@McNets it's not that hard to spend a lot that way

> Oracle OpenWorld Europe Returns to London in February 2020 – Register Today

comical

@dezso this is my usual round-trip if I have time after work goo.gl/maps/eFvw45jsxo19Yzoq6

@McNets quite some elevation to fight with

I wish there was something similar around Berlin :D

@dezso basically that's the only advantage living on a village

haha, planning 2 hours, execution 20 ms.

a very well drafted plan I'd say!

it must be a good plan, the execution time is quite decent

@ypercubeᵀᴹ you are talking about sex, isn't it?

20ms is a very long time in that regard

@dezso is there a dba.se group? :p

I recently started logging my efforts on strava too

blog.sqlauthority.com/2019/09/19/…

Well. I see 0 faults in that logic

@dezso I added you.

@TomV noticed, with not a small amount of surprise

@TomV unaware of

if there are more than two of us, it would be fun

I mostly see rides from around the area, which is boring after a while :D

@dezso surprised that I knew how to find you?

I know your first name and when adding your employer Google gave me your full name

@dezso I don't ride that much. Takes too much time. I run fairly regularly though

the osint is real

@George.Palacios Are you questioning someone's authority in here?

Oh, I’m on Strava

@Philᵀᴹ if you look for dezso you'll find both of us. His name is uncommon enough to find easily. There are hundreds with your name and I'm just Tom V so there are enough of those too

Yeah, already have a Chicu

:-)

You can get me via that route

I hate SCHEMA_NAME()

So annoying. Not the first time I have had working query that I needed to call across in another database and had to rewrite it.

Even if there was database.schema_name() so you could just keep the structure. But no, now you have to join in database.sys.schemas and alias all your shit

or just expose schema name in sys.service_queues or whatever - all those internal views are horrible for accessing from other dbs.

You leave my service broker alone

So related to that... If my message processing in service broker is basically idempotent - I just am getting notifications and then doing some updates which I can do over and over again, do I really need transactions? The problem is that when I start a transaction before the RECEIVE, and then do my stuff, if it fails and there was any application-level logging in the process, that logging is lost. I could just log all the errors, complete the conversation and move on.

We make use of table variables to get around the potential for rollback loss of error logging

There's just way too many places in the processing where it can fail. The message gets sent to a dispatcher that identifies the proc and some of the procs may themselves enumerate a table of steps they need to call to process the notification. I'll think about that, but it seems like the table would need to be passed in very far and out very far.

Right now what I'm doing for testing the various errors I'm injecting is that I can run the processes directly without being in the handler transaction. That's how I ended up with my schema name problem. I had a perfectly good working query, and I moved it into the test database that drives the tests, and it wasn't waiting for the queue to be processed or be disabled because SCHEMA_NAME(schema_id) from otherdb.sys.service_queues was NULL of course...