July 26, 2017 at 11:18 am
This idea is based on a 'blog article of the same name that I wrote a while back.
I was just thinking about how people could get more involved with SQL Saturday (or other conferences, for that matter). In my 'blog article, I talk about my own involvement with SQL Saturday and how I got started as a speaker. I knew that I wanted to contribute, but I didn't know how. I eventually came to the realization that (1) I had expertise I wanted to share, and (2) I am not -- and don't have to be -- a SQL Server guru. I started giving talks on the professional development track, and have spoken at several SQL Saturdays since then.
I'm thinking about taking that and making a presentation out of it.
What do you think, folks? Would it make a good presentation?
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
July 26, 2017 at 11:29 am
I'd enjoy it. I know I have wanted to start speaking in general and plan on doing a presentation at my local chapter sometime soon. But I have also been saying "soon" for over a year now and not presented.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 26, 2017 at 1:51 pm
Do it.
I've never spoken to the local UG (save for a 15 minute lightning presentation 12 years ago)...jumped right in to SQL Saturdays and its a blast 🙂
Did Houston and Chattanooga back to back last month, then wrote this:
http://dallasdbas.com/thoughts-new-speaker/
------------------------------------------------------------------------------------------------Standing in the gap between Consultant and ContractorKevin3NFDallasDBAs.com/BlogWhy is my SQL Log File HUGE?!?![/url]The future of the DBA role...[/url]SQL Security Model in Plain English[/url]
July 26, 2017 at 2:30 pm
I am planning on speaking soon... just need to get some demo scripts and some stuff set up.
I am hoping to do a presentation on troubleshooting service broker. I've had to do some weird troubleshooting at work, so was thinking it would be a fun topic to cover.
Things like message poisoning when using triggers on a message logging table and messaging from SQL 2016 to an older version (encryption is different by default so if you don't specify the encryption, the message can look like it sent from the sender but never arrive) and things like that. Start by showing "this is the thing that is happening", get suggestions from the group about how to solve it (the local group is pretty small, so participation shouldn't impact timing too badly) and then show them how I would troubleshoot it. Doesn't mean my method is the best way; MOST of the time, I troubleshoot service broker by re-sending the failed message with profiler attached to watch what is going on, but it does depend on the problem... poison messages I don't do that as it wouln't be that helpful.
the first step is to get service broker running on 2 different SQL instances on my laptop. That thing is not very powerful (2 GB of RAM :/) so I'm hoping I don't kill the poor little thing. But get SQL up with 2 versions (2012 and 2016), then get service broker up and running, then get scripts to break and repair it.
The big thing with it is that I will not be presenting it as a "best practice" by any means. I am no expert in service broker.
Nice thing is I am the local chapter leader, so if I am not ready to present, it is all on me to get a different thing ready. And I try to have a backup plan figured out before I have to present. Heck, I bring 2 projectors to each meeting just in case one fails and I have the presentation we are going over on USB key in case my laptop decides to not cooperate.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 31, 2017 at 3:35 pm
Well, I just submitted an abstract for SQL Saturday in Providence, RI in December!
Now I just need to come up with a presentation!
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
July 31, 2017 at 7:03 pm
bmg002 - Wednesday, July 26, 2017 2:30 PMI am planning on speaking soon... just need to get some demo scripts and some stuff set up.
I am hoping to do a presentation on troubleshooting service broker. I've had to do some weird troubleshooting at work, so was thinking it would be a fun topic to cover.Things like message poisoning when using triggers on a message logging table and messaging from SQL 2016 to an older version (encryption is different by default so if you don't specify the encryption, the message can look like it sent from the sender but never arrive) and things like that. Start by showing "this is the thing that is happening", get suggestions from the group about how to solve it (the local group is pretty small, so participation shouldn't impact timing too badly) and then show them how I would troubleshoot it. Doesn't mean my method is the best way; MOST of the time, I troubleshoot service broker by re-sending the failed message with profiler attached to watch what is going on, but it does depend on the problem... poison messages I don't do that as it wouln't be that helpful.
the first step is to get service broker running on 2 different SQL instances on my laptop. That thing is not very powerful (2 GB of RAM :/) so I'm hoping I don't kill the poor little thing. But get SQL up with 2 versions (2012 and 2016), then get service broker up and running, then get scripts to break and repair it.
The big thing with it is that I will not be presenting it as a "best practice" by any means. I am no expert in service broker.
Nice thing is I am the local chapter leader, so if I am not ready to present, it is all on me to get a different thing ready. And I try to have a backup plan figured out before I have to present. Heck, I bring 2 projectors to each meeting just in case one fails and I have the presentation we are going over on USB key in case my laptop decides to not cooperate.
I was in a similar situation not too many years ago - I wanted to do a presentation, but couldn't seem to get started. It took a good friend (an experienced and very effective speaker) firmly planting his foot in my butt with a swift kick to get me going. I'd like to pass on some advice he gave to me when I committed to my first real speaking engagement at a SQL Saturday: Get the code written and tested before you start writing your presentation.
It seems almost self-evident now, but I didn't know it before I started doing it.
What chapter do you lead?
August 1, 2017 at 8:38 am
Ed Wagner - Monday, July 31, 2017 7:03 PMbmg002 - Wednesday, July 26, 2017 2:30 PMI am planning on speaking soon... just need to get some demo scripts and some stuff set up.
I am hoping to do a presentation on troubleshooting service broker. I've had to do some weird troubleshooting at work, so was thinking it would be a fun topic to cover.Things like message poisoning when using triggers on a message logging table and messaging from SQL 2016 to an older version (encryption is different by default so if you don't specify the encryption, the message can look like it sent from the sender but never arrive) and things like that. Start by showing "this is the thing that is happening", get suggestions from the group about how to solve it (the local group is pretty small, so participation shouldn't impact timing too badly) and then show them how I would troubleshoot it. Doesn't mean my method is the best way; MOST of the time, I troubleshoot service broker by re-sending the failed message with profiler attached to watch what is going on, but it does depend on the problem... poison messages I don't do that as it wouln't be that helpful.
the first step is to get service broker running on 2 different SQL instances on my laptop. That thing is not very powerful (2 GB of RAM :/) so I'm hoping I don't kill the poor little thing. But get SQL up with 2 versions (2012 and 2016), then get service broker up and running, then get scripts to break and repair it.
The big thing with it is that I will not be presenting it as a "best practice" by any means. I am no expert in service broker.
Nice thing is I am the local chapter leader, so if I am not ready to present, it is all on me to get a different thing ready. And I try to have a backup plan figured out before I have to present. Heck, I bring 2 projectors to each meeting just in case one fails and I have the presentation we are going over on USB key in case my laptop decides to not cooperate.
I was in a similar situation not too many years ago - I wanted to do a presentation, but couldn't seem to get started. It took a good friend (an experienced and very effective speaker) firmly planting his foot in my butt with a swift kick to get me going. I'd like to pass on some advice he gave to me when I committed to my first real speaking engagement at a SQL Saturday: Get the code written and tested before you start writing your presentation.
It seems almost self-evident now, but I didn't know it before I started doing it.
What chapter do you lead?
I lead the Saskatoon SQL Server User Group. Still feel very new, but we have been running for nearly 2 years. Started January 2016 with a meeting at a restaurant to discuss topics people would be interested in, heard absolutely no feedback, so just picked things thay sounded interesting to me. The group is still pretty small; we have 17 registered members and average attendance of 4 people. This is not great, but it isn't horrible either. This coming year I know I need to advertise better.
And I agree. Getting the code working I think will be the hard part. That and getting the timing good. But the group is very flexible. The presentation window is from 1:30 until 4:00.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
August 1, 2017 at 9:07 am
bmg002 - Tuesday, August 1, 2017 8:38 AMEd Wagner - Monday, July 31, 2017 7:03 PMbmg002 - Wednesday, July 26, 2017 2:30 PMI am planning on speaking soon... just need to get some demo scripts and some stuff set up.
I am hoping to do a presentation on troubleshooting service broker. I've had to do some weird troubleshooting at work, so was thinking it would be a fun topic to cover.Things like message poisoning when using triggers on a message logging table and messaging from SQL 2016 to an older version (encryption is different by default so if you don't specify the encryption, the message can look like it sent from the sender but never arrive) and things like that. Start by showing "this is the thing that is happening", get suggestions from the group about how to solve it (the local group is pretty small, so participation shouldn't impact timing too badly) and then show them how I would troubleshoot it. Doesn't mean my method is the best way; MOST of the time, I troubleshoot service broker by re-sending the failed message with profiler attached to watch what is going on, but it does depend on the problem... poison messages I don't do that as it wouln't be that helpful.
the first step is to get service broker running on 2 different SQL instances on my laptop. That thing is not very powerful (2 GB of RAM :/) so I'm hoping I don't kill the poor little thing. But get SQL up with 2 versions (2012 and 2016), then get service broker up and running, then get scripts to break and repair it.
The big thing with it is that I will not be presenting it as a "best practice" by any means. I am no expert in service broker.
Nice thing is I am the local chapter leader, so if I am not ready to present, it is all on me to get a different thing ready. And I try to have a backup plan figured out before I have to present. Heck, I bring 2 projectors to each meeting just in case one fails and I have the presentation we are going over on USB key in case my laptop decides to not cooperate.
I was in a similar situation not too many years ago - I wanted to do a presentation, but couldn't seem to get started. It took a good friend (an experienced and very effective speaker) firmly planting his foot in my butt with a swift kick to get me going. I'd like to pass on some advice he gave to me when I committed to my first real speaking engagement at a SQL Saturday: Get the code written and tested before you start writing your presentation.
It seems almost self-evident now, but I didn't know it before I started doing it.
What chapter do you lead?
I lead the Saskatoon SQL Server User Group. Still feel very new, but we have been running for nearly 2 years. Started January 2016 with a meeting at a restaurant to discuss topics people would be interested in, heard absolutely no feedback, so just picked things thay sounded interesting to me. The group is still pretty small; we have 17 registered members and average attendance of 4 people. This is not great, but it isn't horrible either. This coming year I know I need to advertise better.
And I agree. Getting the code working I think will be the hard part. That and getting the timing good. But the group is very flexible. The presentation window is from 1:30 until 4:00.
Well, persistence and consistency are key, so keep at it. The group here in metro Detroit hasn't met in quite a few months and it's discouraging to some of us. I now travel 75+ miles every month to visit the next closest one. I tell you this so you don't fall into the same trap. Advertising gets the word out, as does word of mouth. All the best with growing the group.
August 1, 2017 at 9:51 am
Ed Wagner - Tuesday, August 1, 2017 9:07 AMbmg002 - Tuesday, August 1, 2017 8:38 AMEd Wagner - Monday, July 31, 2017 7:03 PMbmg002 - Wednesday, July 26, 2017 2:30 PMI am planning on speaking soon... just need to get some demo scripts and some stuff set up.
I am hoping to do a presentation on troubleshooting service broker. I've had to do some weird troubleshooting at work, so was thinking it would be a fun topic to cover.Things like message poisoning when using triggers on a message logging table and messaging from SQL 2016 to an older version (encryption is different by default so if you don't specify the encryption, the message can look like it sent from the sender but never arrive) and things like that. Start by showing "this is the thing that is happening", get suggestions from the group about how to solve it (the local group is pretty small, so participation shouldn't impact timing too badly) and then show them how I would troubleshoot it. Doesn't mean my method is the best way; MOST of the time, I troubleshoot service broker by re-sending the failed message with profiler attached to watch what is going on, but it does depend on the problem... poison messages I don't do that as it wouln't be that helpful.
the first step is to get service broker running on 2 different SQL instances on my laptop. That thing is not very powerful (2 GB of RAM :/) so I'm hoping I don't kill the poor little thing. But get SQL up with 2 versions (2012 and 2016), then get service broker up and running, then get scripts to break and repair it.
The big thing with it is that I will not be presenting it as a "best practice" by any means. I am no expert in service broker.
Nice thing is I am the local chapter leader, so if I am not ready to present, it is all on me to get a different thing ready. And I try to have a backup plan figured out before I have to present. Heck, I bring 2 projectors to each meeting just in case one fails and I have the presentation we are going over on USB key in case my laptop decides to not cooperate.
I was in a similar situation not too many years ago - I wanted to do a presentation, but couldn't seem to get started. It took a good friend (an experienced and very effective speaker) firmly planting his foot in my butt with a swift kick to get me going. I'd like to pass on some advice he gave to me when I committed to my first real speaking engagement at a SQL Saturday: Get the code written and tested before you start writing your presentation.
It seems almost self-evident now, but I didn't know it before I started doing it.
What chapter do you lead?
I lead the Saskatoon SQL Server User Group. Still feel very new, but we have been running for nearly 2 years. Started January 2016 with a meeting at a restaurant to discuss topics people would be interested in, heard absolutely no feedback, so just picked things thay sounded interesting to me. The group is still pretty small; we have 17 registered members and average attendance of 4 people. This is not great, but it isn't horrible either. This coming year I know I need to advertise better.
And I agree. Getting the code working I think will be the hard part. That and getting the timing good. But the group is very flexible. The presentation window is from 1:30 until 4:00.
Well, persistence and consistency are key, so keep at it. The group here in metro Detroit hasn't met in quite a few months and it's discouraging to some of us. I now travel 75+ miles every month to visit the next closest one. I tell you this so you don't fall into the same trap. Advertising gets the word out, as does word of mouth. All the best with growing the group.
Thanks. And yes, I try to be persistant and consistant. I host the meeting on the last Friday of the month at 1:30 PM for every month except October (PASS Summit) and December (Christmas). I do notice a small decline in the summer, but as long as I get 1 person attending, I am happy.
The other thing I am going to do starting next year is get more sponsorship so I can offer prizes and/or snacks. I think that would encourage more people to come. I have a prize pack coming in the mail that I am thinking I'm going to hand out in the November or January meetings. Not sure which yet. Debating on if it should be a "Year end" prize or a "New year" prize. I suppose it all depends when it gets here. It was shipped a while back and I've heard nothing. Might need to poke the vendor.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
August 1, 2017 at 10:08 am
Ray K - Monday, July 31, 2017 3:35 PMWell, I just submitted an abstract for SQL Saturday in Providence, RI in December!Now I just need to come up with a presentation!
If I could swing it I'd try to come out there. Spend a day visiting my daughter at college, then attend SQL Saturday, then spend a little more time with my daughter and then fly back home. Would only need to take a couple of days PTO. Just not sure I would have the money to fly out and stay three nights.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply