I forgot to mention this is in SQL Server, so SIN operates on radians. So I THINK this can only ever cast to a 0 when clientId is also 0
It certainly doesn't for any of the 100,000 existing rows
I forgot to mention this is in SQL Server, so SIN operates on radians. So I THINK this can only ever cast to a 0 when clientId is also 0
It certainly doesn't for any of the 100,000 existing rows
The client table has around 100,000 rows each with a unique clientId, none of which are returned from the CAST / ABS / SIN
I think you are right and this is a 'fix' for something lost to time. I am going to talk to the original dev tomorrow to see if they remember what it was for
Thank you so much, I'll check it out!
Absolutely, it's a great read. Could you link the video you watched?
I think it is a bug and here's why
I have setup a lemmy instance to understand how it works and hopefully contribute something meaningful
My instance has 2 users, both are subscribed to the same cross-instance community, but only one is showing Subscribe Pending even if I un-sub and re-sub
I am not aware of any approval system to subscribe to a community, so I believe the approval was received the community instance, but the "accept" response data was missed / dropped when returning to your host instance
Let me make sure I understand first
i added my private key, and tried to connect
This concerns me, as the server should have the user's public key, not private. Private should be exactly that, private
Is the Powershell user / SSH key the same as the Putty user / SSH key that still works?
When you run the Powershell script, does it give any error messages?
I know with Linux -> Linux SSH you can log verbosely with -v, is that something you can do under Powershell?
Is password auth enabled? Does that still work from Putty, and can you do the same from Powershell?
Oh yeah, I remember listening to that when they only had around 5 episodes
They still do the high-pitched beep when you start or stop I see haha
Thank you
Update: The original dev does not remember exactly. However they have said that
clientIdwas originally a VARCHAR, so this may have been checking for both'0'or''So an over-engineered workaround to a bad datatype perhaps?