Event invitation – Women Techmakers Montreal

Invitation to join online event: Women Techmakers Montreal!

Hello everyone! Today’s post is an invitation to the Women Techmakers Montreal event.

Women Techmakers is a program created by Google to celebrate International Women’s Day and to highlight the talent of women in technology. This program has been in over 200 global events and seen across 52 countries. The next event will be on Saturday, March 20, 2021.

Last year, I remember being really excited to go to the event in Montreal, when COVID hit and events all over were cancelled. Luckily, the organization switched to an online event instead. It was an amazing day! Full of such inspiring women, and such a beautiful community.

This year, I wanted to: 1- let more people know about the event, and 2- get people to join the event!

Who can join?

All genders are welcome! If you’re into tech, I’m positive you’ll find a topic that will get your attention. Sign up and enjoy (:

The event is totally free and lasts the whole day (from 9AM to 6PM EST). Check out their amazing agenda.

If you’re wondering about what happened last year, check this playlist with their sessions.

Find more info on their site.

I hope to see you there!

T-SQL Tuesday – My (least) favorite SQL data type: DATE

Hello! This post is a contribution to T-SQL Tuesday. T-SQL Tuesday is a monthly blogothon where we get together and write about a different topic. March’s topic was to blog about you favorite data type, hosted by Brent Ozar.

I wrote two versions of this post. This one you’re reading in English, and this one in Portuguese.

If you work with data, you probably do not have control over all the data sources you need. What I mean, is that for example, you may receive data from different places. Perhaps it’s your job to centralize and standardize it the best you can, so that it makes sense to your team. Once you understand the data, value can be extracted from it.

When your data comes from different systems, it’s likely you will not have control over the data’s validation. For example, one of you vendors may be very specific about the data types allowed into their systems, which means when the data gets to you, you’ll see something (ideally) more structured. However, your data may also be handled by a group of fed up developers who decided they will allow everything the user wants (special attention to the the verb there being want instead of need, big difference).

Date data types are really important and used in SQL. But for humans, dates can be formatted in some ways… For example, I’m from Brazil, and the way we write our dates is different from the US.

  • Brazil: DD/MM/YYYY
  • US: MM/DD/YYYY

In SQL, your date type stores data like this: YYYY-MM-DD. No room for mistakes, right? Bam, Wrong.

Remember when I said you may have different data sources and you can’t control their data type validations? Let’s think of the following example:

  • Your clients use a 3rd part system
  • The 3rd party uses the data to do whatever it is their system does
  • They send you that data with the results of your project
  • You, a smart data person, tries to load the data into your system. Most importantly, your system is formatted with the data types you expect to receive. So, for example, if you expect a field with a date value, you’ll format your table to have a date type column.
  • Let’s use the table “ThirdPartyInfo” as an example.

Now, as should have assumed by now, your third party did not applied any data validation to the date types. Hence, you may get some crazy “dates”, like this:

  • Jan/2021
  • 03-20-18
  • 01-02-03 (where to even begin with this one?!)
  • 2022/2
  • and many others….

Here’s what happens when you try to insert something that’s not a date, into any of the date columns:

It does not matter the method you’ll use to input data to your table, you’ll get an error if you’re not passing date values to your date types columns.

How can you avoid issues like this

  • Be open to your vendor about why this is important to your data, and explain to them your tables data type. How? Documenting, the thing IT people hate most.
  • If the vendor is pushing back, talk to your superiors, and show them a scenario in which you need to spend your precious (expensive) time to fix this mishap. Enforce this could be avoided if everyone were on the page about the data types for the data you share.
  • If nothing above works, or you need a temporary solution, you could validate the data on your end too. More work upfront, but your future self will thank you for putting this effort now.

Learning it the hard way

  • Real life example: I recently had an issue that cost me a lot of time. I had received a csv I needed for reporting, and the file had a few date fields. My table, was expecting date types to come in all the fields, but I was getting errors on my data loading job.
    • I had to take a step back and find where the issue was. I thought it would be easy to find, by checking the most recent info that got into the system (this was a daily file we received), and so I started looking for the issue. My main mistake, was that I did not isolate the date column that was giving me an error. In the SQL Server, the error message was really vague, I could only tell there was a string trying to be converted to date and I had several different date fields in my table.
    • My second big mistake was fixing everything I found on the source file, and I thought was wrong and causing the issues. Spoiler alert: it wasn’t.
    • It took me some time to realize that “ISDATE” was an easy way to search for a column that is expecting a date type, but received something else instead:
In desperate times, we may be blind by stress and not think about simple things, like this.

You see that the return to that query has the string value. Now, you could apply this kind of check as a validation before you load data into your production table, and also use it to troubleshoot issues like mine.

With all that being said, I actually like the DATE data type in SQL. It works great, the real issue is that we as humanity never agreed on a single date format. Sigh. I hope this helps!

If you want you can read more about the Date types here: Date types in SQL

Would you solve my problem in a different way? Tell me how below in the comments (:

Commenting and Naming practices with T-SQL scripts

Image: https://tinyurl.com/pt8ly0ix

Do you know that feeling when you’re starting another query and this time you’re thinking “I won’t re-use this… this is a one-time thing…”. We both know you’re lying.

I said that because most of the time:

  • you’re code is reusable
  • you’re human and you forget stuff, so perhaps tomorrow you forgot something you realized how to do today
  • I’ve never seen where you keep your scripts but I bet that needs a clean up

When you’re working on something, try to picture your future self. Your older self has probably no clue about what this *really_important_2018_script* project was. Is your older/wiser version happy while reading that? I don’t think so.

If you make an effort now to be more “tidy” with your code, here’s who will be happy:

  • your future self
  • your colleagues who read your code
  • people who will take your job in the future and think “hey! this person don’t suck as much as I thought… just a little!”

How to add comments in SQL

Basically, there are two ways to add comments in SQL:

1- add “–” and start typing!

2- add “/**/” and write in between the stars.

No one is better than the other. The first option is usually for in-line smaller comment. The second it’s more for commenting out blocks of code or writing bigger comments in a way they will not be on one same line.

Initial comments

Personally, I believe comments are a good thing. It’s not something I do with every line, however, when I open a new query, I automatically add my comments.

Here’s how I like to start my scripts:

Important note: if you’re writing a stored procedure, remember to add this block of comments after your “CREATE PROCEDURE” statement. When you do so, the comment will show up when you right-click on the stored procedure and chose “Modify”. Otherwise it’s gone and saved only on your main script file.

Naming your file

Try to be descriptive when naming your file, and don’t abbreviate too much. The name you chose may seem relevant now, but again, ask yourself “is my future version hating me now?”. If the answer is yes, than chose something else.

If the script you are creating is part of a bigger project that involves other scripts, then try to start every file name with something that refers to the project itself.

For example: sp_AutomatedFinancialReports_CalculatingEmployeeSalary

Here’s what we know based on the file name:

  • sp: this is a stored procedure
  • AutomatedFinancialReports: project name that’s descriptive
  • CalculatingEmployeeSalary: this is what your specific script will do as part of the project

Avoid at all costs using “new”, “old”, “final” and relative names on your file. This is not useful long-term. If you’re creating many drafts, I’d go with versions like “v1”, “v2”, or just add the plain date to your file name. But remember this is a temporary name, and that once you figure your “v23_final_new” file, you’ll change the name accordingly. Another trick is to move your thousand drafts to a, guess what, drafts folder. The idea is that your main project folder keeps your already tested and ready to go script.

This is some basic stuff I do everyday and I hope you find it useful. Do you add something else that you’d like to share? Leave a comment (:

Want to read this post in Portuguese? Check out this link.

See you later!

Get to know me

Hello!

As my first official post on this site, I’d like to introduce myself, share what I’d like to talk about as well as my writing goals.

My name is Camila Henrique. I’m from Indaiatuba, a small city in São Paulo, Brazil. I am living in Montreal, Canada, as I’m writing this in January 2021. I’ve worked with Microsoft SQL Server since 2015. Today I’m a DBA/SQL Dev in a medium size agency. Last but not least, I speak Portuguese, English and French, and I love learning new languages.

What will I talk about?

I’ve always been someone who really appreciates having a mentor. Be that at school or work. I just find it better when someone can guide me towards good decisions. However, I also know how hard it is for people who are just beginning their professional life, to find a good mentor. I’m not by any means trying to replace that person in your life right now, but I’d like to help. So, for you, my dear beginner IT person – I will talk about first steps you can to take in your career.

If you’re into SQL, wondering about first steps, or searching about specific data things, I’ll post beginner tips and tricks that you can practice in real life.

I believe we, information technology humans, often misjudge the importance of knowing how to properly communicate with other humans. No matter what you do, I’m sure your work involves talking to other people, and well, we’re not really known for that. That’s why I want to share things I’ve learned about communication.

If you’re someone who natively speaks Portuguese, like me, I’d like to assist on your bilingual journey by posting in both Portuguese and English, so you can chose and practice as you’d like. I’d love to be part of my country’s community, as well as reaching more people with my English content.

I’m also passionate about topics that involve diversity at work, and sometimes I find it hard to talk about that in the tech field. That’s why this will be one of the topics I’ll present here.

And because I know people like “personal” stuff: I’m into yoga, I love drawing and I definitely buy more books than I read and do not recommend that (but won’t judge you either, welcome to the club!).

I hope we get to spend some wonderful time together. If you follow me, let me know about you in the comments, I’d love to make more internet friends.

See you!