These databases are created at installation and they're specified to be 1,2,3,4 as you wrote. You can always break a system if you meddle with it, and Microsoft can change these databases, both in IDs and in purpose. MS could make a second model db for different purposes called "model2", or add a second tempdb database to split different types of temporary tables, or for whatever reason.

My advice is a) be reassured that in current versions of SQL Server these database IDs are consistent (at installation). I have also never seen them otherwise. If you are particularly concerned or just can't shake that nagging feeling, verify these facts at the beginning of your program/script, specifically ID # = db name string.

I like to track my assumptions that I make in code as I write it. For in-house code, these db name and ID assumptions are pretty safe. For outside clients I prefer to verify everything. It helps a) get it out of your head, whether it's this db name/ID assumption or something else, and b) if one of these assumptions does break, you can find it very fast. It saves a lot of head scratching, and it's reassuring to know what you can count on.

When you hit these questions, just verify and move on (although there's no harm in posting the question too, like you did). In this way your time is better spent on actual issues, and you can clear your head of these nagging questions. And it gives you confidence when things fail, it's not one of these verified questions.

In this particular case, I've never felt the need to verify these database IDs; I've always accessed them via their functionality, not directly. However, if I were writing a script to operate on these databases, knowing the ramifications could be severe if the environment is not what I expect it to be, I would definitely verify my assumptions.

These databases are created at installation and they're specified to be 1,2,3,4 as you wrote. You can always break a system if you meddle with it, and Microsoft can change these databases, both in IDs and in purpose. MS could make a second model db for different purposes called model2, or add a second tempdb database to split different types of temporary tables, or for whatever reason.

My advice is: be reassured that in current versions of SQL Server these database IDs are consistent (at installation). I have also never seen them otherwise. If you are particularly concerned or just can't shake that nagging feeling, verify these facts at the beginning of your program/script, specifically ID # = db name string.

I like to track the assumptions that I make in code as I write it. For in-house code, these db name and ID assumptions are pretty safe. For outside clients I prefer to verify everything. It helps a) get it out of your head, whether it's this db name/ID assumption or something else, and b) if one of these assumptions does break, you can find it very fast. It saves a lot of head scratching, and it's reassuring to know what you can count on.

When you hit these questions, just verify and move on (although there's no harm in posting the question too, like you did). In this way your time is better spent on actual issues, and you can clear your head of these nagging questions. And it gives you confidence when things fail, it's not one of these verified questions.

In this particular case, I've never felt the need to verify these database IDs; I've always accessed them via their functionality, not directly. However, if I were writing a script to operate on these databases, knowing the ramifications could be severe if the environment is not what I expect it to be, I would definitely verify my assumptions.

These databases are created at installation and they're specified to be 1,2,3,4 as you wrote. You can always break a system if you meddle with it, and Microsoft can change these databases, both in IDs and in purpose. MS could make a second model db for different purposes called "model2", or add a second tempdb database to split different types of temporary tables, or for whatever reason.

My advice is a) be reassured that in current versions of SQL Server these database IDs are consistent (at installation). I have also never seen them otherwise. If you are particularly concerned or just can't shake that nagging feeling, verify these facts at the beginning of your program/script, specifically ID # = db name string.

I like to track my assumptions that I make in code as I write it. For in-house code, these db name and ID assumptions are pretty safe. For outside clients I prefer to verify everything. It helps a) get it out of your head, whether it's this db name/ID assumption or something else, and b) if one of these assumptions does break, you can find it very fast. It saves a lot of head scratching, and it's reassuring to know what you can count on.

When you hit these questions, just verify and move on. In this way your time is better spent on actual issues, and you can clear your head of these nagging questions. And it gives you confidence when things fail, it's not one of these verified questions.

In this particular case, I've never felt the need to verify these database IDs; I've always accessed them via their functionality, not directly. However, if I were writing a script to operate on these databases, knowing the ramifications could be severe if the environment is not what I expect it to be, I would definitely verify my assumptions.

These databases are created at installation and they're specified to be 1,2,3,4 as you wrote. You can always break a system if you meddle with it, and Microsoft can change these databases, both in IDs and in purpose. MS could make a second model db for different purposes called "model2", or add a second tempdb database to split different types of temporary tables, or for whatever reason.

My advice is a) be reassured that in current versions of SQL Server these database IDs are consistent (at installation). I have also never seen them otherwise. If you are particularly concerned or just can't shake that nagging feeling, verify these facts at the beginning of your program/script, specifically ID # = db name string.

I like to track my assumptions that I make in code as I write it. For in-house code, these db name and ID assumptions are pretty safe. For outside clients I prefer to verify everything. It helps a) get it out of your head, whether it's this db name/ID assumption or something else, and b) if one of these assumptions does break, you can find it very fast. It saves a lot of head scratching, and it's reassuring to know what you can count on.

When you hit these questions, just verify and move on (although there's no harm in posting the question too, like you did). In this way your time is better spent on actual issues, and you can clear your head of these nagging questions. And it gives you confidence when things fail, it's not one of these verified questions.

In this particular case, I've never felt the need to verify these database IDs; I've always accessed them via their functionality, not directly. However, if I were writing a script to operate on these databases, knowing the ramifications could be severe if the environment is not what I expect it to be, I would definitely verify my assumptions.