Timeline for SQL Server FILELISTONLY command providing incorrect logical database name
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 29, 2014 at 18:45 | vote | accept | Lumpy | ||
| May 29, 2014 at 16:08 | answer | added | Aaron Bertrand | timeline score: 2 | |
| May 29, 2014 at 15:49 | comment | added | Lumpy | @AaronBertrand - since the front of the house can use that stored procedure to create databases from "template databases" ie just another db. and then use those new databases to create other databases I can't tell. I suspect that database 423 is in database 4295's ancestry at some point. Did that make sense? | |
| May 29, 2014 at 15:46 | comment | added | Aaron Bertrand |
Where exactly did the database 4295 come from? Was it ever restored from a backup of a database named 423? I think you're tripping over yourself by using this templating system to make databases based on backups of other databases. As I suggested in your other question, you should really consider using the model database for this - that's exactly what it's for.
|
|
| May 29, 2014 at 15:46 | history | edited | Lumpy | CC BY-SA 3.0 |
edited body
|
| May 29, 2014 at 15:45 | comment | added | Lumpy | @AaronBertrand - So just to make sure I'm answering fully. I get 423 both from the procedure which is referenced in the old ticket and also if I run the command listed in my previous comment. while if I use the SSMS GUI I have a different value listed. | |
| May 29, 2014 at 15:44 | comment | added | Lumpy | @AaronBertrand - Now I get you. When I run the following RESTORE FILELISTONLY FROM DISK = 'S:\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\TemplateCopy\4295.BAK' I receive the 423 value. I made a type above. Its 423 not 349. I'll fix that. | |
| May 29, 2014 at 15:39 | comment | added | Aaron Bertrand | Let me ask a different way. When you do FILELISTONLY with code, you get 349. What happens when you do FILELISTONLY manually? Do you see 349 or 3497? Do you see what I'm getting at? Trying to isolate if this is a problem with your database (doubt it) or your code (highly likely). | |
| May 29, 2014 at 15:34 | comment | added | Lumpy | @AaronBertrand - I'm sorry Aaron. Yes I'm referring to the code referenced in the linked ticket when I say using code. and the without using code refers to using the SSMS GUI to do the backup and restore. Please see my comment to Bob Pusateri. | |
| May 29, 2014 at 15:31 | comment | added | Lumpy | @BobPusateri - by manual I'm referring to using the SSMS GUI. Under Options the Original File Name is listed as 3497. I've found in the past that if I hardcode my procedure to use that same value that the procedure works fine. | |
| May 29, 2014 at 15:31 | comment | added | Aaron Bertrand | Which question are you answering? I asked two. Can you be explicit? | |
| May 29, 2014 at 15:30 | comment | added | Lumpy | @AaronBertrand - You caught me. Yes sir that is what I mean. | |
| May 29, 2014 at 15:24 | comment | added | Bob Pusateri |
By "manual restore" do you mean actually restoring the database and bringing it online? How are you determining the logical file name after doing this restore? sys.database_files?
|
|
| May 29, 2014 at 15:22 | comment | added | Aaron Bertrand |
When you say "using code" can I assume you mean you are still using all of this jazz? And that you get different results when you use RESTORE FILELISTONLY without using code?
|
|
| May 29, 2014 at 15:16 | history | asked | Lumpy | CC BY-SA 3.0 |