Hello!
I'm new to this forum as my position changed within the last year from Box Office Manager to a more IT related field of Tessitura Database Manager. I've been learning a great deal through Tessitura training courses offered and the assistance of Tessitura support, however I hit a road block when it comes to anything requiring SQL knowledge which pops up very frequently. Since I didn't come from an IT background, I'm lost when it comes to this and it gets tough when I keep having to go to Consulting and present a charge to Administration to get a task completed. Do any of you have advice on how to gain basic SQL knowledge to do tasks in Tessitura. And if there are any of you who were in this same position, how did you go about learning and moving forward?
Thank you so much,
Melanie
Melanie,
This seems to be a common path into the dark arts of SQL - my own included. As others have mentioned, W3Schools and stack Overflow are great resources but the VERY BEST resource is the Tessitura community. The folks here are unflinchingly generous with their time and expertise, probably because we've all been in the same position. And we know the Tessi database pretty well by now - there probably isn't a scenario one of us hasn't encountered!
As someone who's made a couple of disastrous mistakes, please, please, please hone your skills with SELECT statements first and ALWAYS remember to try anything that deletes or updates in your TEST environment first.
Something I wish I was told at the start … when you are going to INSERT/UPDATE/DELETE into the data base learn to use a BEGIN TRANSACTION / ROLLBACK TRANSACTION statement.
If ever I've thought about doing something daft (I won't give examples) and I figure I should probably run it by Tessitura Support first, do it.
Fully agreed. When you do get to the point of actually making changes to the database, make sure to use Transactions/all of the safety tools at your disposal to avoid doing something like... well, I have my own examples that probably compare well with Heath's. Error handling is exceptionally useful, but I did not embrace it early on. I had liked to think "but I write GOOD code that does not cause errors, so that is not needed"... but that was me being dumb. Even the best code can run and do exactly what it is supposed to do and end up causing an error because the source information was something completely unanticipated and/or at fault itself.
And indeed be certain to test it in your TEST database first (I still do not do that enough).