SQL Server Must Die
-
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrgggggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: Did you ever get so frustrated with something that you flailed about and during that flailing you deleted something important and found you are royally screwed? I was trying to import some data from Excel into a database in SQL Server. No problem... wrong. First the Excel fields were too large for DTS to import.. WTF? Too large? Excel can handle bigger fields than SQL? Huh? WTF?!?! Anyway, so I ignored the large fields and imported the smaller ones fine. I then had to import another similar Excel file, got half way when SQL reported that it could not continue because the Transaction log was full. It told me to back it up and clear it. I tried this, only to have the backup say "Error while backing up, writing to transaction log"... You guessed it, the trans log was full obviously (hence why I was backing up) so it failed in trying to write the trans log backup transaction error... keh? wtf?!?! So I just went, shut down SQL server and delete the bloody Transaction log. I mean, who needs it right? All I am doing is development, no need for transaction logging yet... Much to my horror SQL NEEDS that trans log to keep the database running. Much to my horror deleting a transaction log is the same as deleting the database file (wtf?!?! why is that?) So instead of just loosing all the transactions, I lost the whole database. The last backup I did was three days ago, one day before I created all my tables, views, triggers, stored procedures AND EVERY OTHER FLUFFING OBJECT! So now, I have two tables out of 100 and am recreating them all with the aid of VS.NET and datasets... :mad: :mad: :mad: :mad: :mad: :mad: :mad: backups, restores and transaction logs in SQL Server are a real cock up IMO. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
Paul Watson wrote: Much to my horror deleting a transaction log is the same as deleting the database file There is an option... you could use the sp_attachdb stored procedure to reattach the ".mdf" file. This way you´ll have a database with all the data since the last transaction log check point. Mauricio Ritter - Brazil Sonorking now: 100.13560 Trank My latest article: Pentominos - A C# implementation of the famous Puzzle Game
-
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrgggggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: Did you ever get so frustrated with something that you flailed about and during that flailing you deleted something important and found you are royally screwed? I was trying to import some data from Excel into a database in SQL Server. No problem... wrong. First the Excel fields were too large for DTS to import.. WTF? Too large? Excel can handle bigger fields than SQL? Huh? WTF?!?! Anyway, so I ignored the large fields and imported the smaller ones fine. I then had to import another similar Excel file, got half way when SQL reported that it could not continue because the Transaction log was full. It told me to back it up and clear it. I tried this, only to have the backup say "Error while backing up, writing to transaction log"... You guessed it, the trans log was full obviously (hence why I was backing up) so it failed in trying to write the trans log backup transaction error... keh? wtf?!?! So I just went, shut down SQL server and delete the bloody Transaction log. I mean, who needs it right? All I am doing is development, no need for transaction logging yet... Much to my horror SQL NEEDS that trans log to keep the database running. Much to my horror deleting a transaction log is the same as deleting the database file (wtf?!?! why is that?) So instead of just loosing all the transactions, I lost the whole database. The last backup I did was three days ago, one day before I created all my tables, views, triggers, stored procedures AND EVERY OTHER FLUFFING OBJECT! So now, I have two tables out of 100 and am recreating them all with the aid of VS.NET and datasets... :mad: :mad: :mad: :mad: :mad: :mad: :mad: backups, restores and transaction logs in SQL Server are a real cock up IMO. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
You can create another database detach the database. Copy the transaction log and attach it to the new one. That would work. You could have just increased the tarnsaction log size.
-
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrgggggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: Did you ever get so frustrated with something that you flailed about and during that flailing you deleted something important and found you are royally screwed? I was trying to import some data from Excel into a database in SQL Server. No problem... wrong. First the Excel fields were too large for DTS to import.. WTF? Too large? Excel can handle bigger fields than SQL? Huh? WTF?!?! Anyway, so I ignored the large fields and imported the smaller ones fine. I then had to import another similar Excel file, got half way when SQL reported that it could not continue because the Transaction log was full. It told me to back it up and clear it. I tried this, only to have the backup say "Error while backing up, writing to transaction log"... You guessed it, the trans log was full obviously (hence why I was backing up) so it failed in trying to write the trans log backup transaction error... keh? wtf?!?! So I just went, shut down SQL server and delete the bloody Transaction log. I mean, who needs it right? All I am doing is development, no need for transaction logging yet... Much to my horror SQL NEEDS that trans log to keep the database running. Much to my horror deleting a transaction log is the same as deleting the database file (wtf?!?! why is that?) So instead of just loosing all the transactions, I lost the whole database. The last backup I did was three days ago, one day before I created all my tables, views, triggers, stored procedures AND EVERY OTHER FLUFFING OBJECT! So now, I have two tables out of 100 and am recreating them all with the aid of VS.NET and datasets... :mad: :mad: :mad: :mad: :mad: :mad: :mad: backups, restores and transaction logs in SQL Server are a real cock up IMO. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
Try Access:-D
-
Try Access:-D
Roger Wright wrote: Try Access Or even old-style flat files Nish ;-)
My miniputt high is now 29 I do not think I can improve on that My temperament won't hold www.busterboy.org
-
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrgggggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: Did you ever get so frustrated with something that you flailed about and during that flailing you deleted something important and found you are royally screwed? I was trying to import some data from Excel into a database in SQL Server. No problem... wrong. First the Excel fields were too large for DTS to import.. WTF? Too large? Excel can handle bigger fields than SQL? Huh? WTF?!?! Anyway, so I ignored the large fields and imported the smaller ones fine. I then had to import another similar Excel file, got half way when SQL reported that it could not continue because the Transaction log was full. It told me to back it up and clear it. I tried this, only to have the backup say "Error while backing up, writing to transaction log"... You guessed it, the trans log was full obviously (hence why I was backing up) so it failed in trying to write the trans log backup transaction error... keh? wtf?!?! So I just went, shut down SQL server and delete the bloody Transaction log. I mean, who needs it right? All I am doing is development, no need for transaction logging yet... Much to my horror SQL NEEDS that trans log to keep the database running. Much to my horror deleting a transaction log is the same as deleting the database file (wtf?!?! why is that?) So instead of just loosing all the transactions, I lost the whole database. The last backup I did was three days ago, one day before I created all my tables, views, triggers, stored procedures AND EVERY OTHER FLUFFING OBJECT! So now, I have two tables out of 100 and am recreating them all with the aid of VS.NET and datasets... :mad: :mad: :mad: :mad: :mad: :mad: :mad: backups, restores and transaction logs in SQL Server are a real cock up IMO. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
Which version of SQL Server are you using? In 7 (if I remember rightly) there is a 'truncated log file' option, and also an auto-truncate option that stops this from being an issue. In 2000 this is set by default. But I'm guessing super-cheerful advice is not gonna help you one little bit at the moment! cheers, Chris Maunder
-
You can create another database detach the database. Copy the transaction log and attach it to the new one. That would work. You could have just increased the tarnsaction log size.
Rama Krishna wrote: You can create another database detach the database. Copy the transaction log and attach it to the new one. That would work. You could have just increased the tarnsaction log size. Yes I could do that, under normal circumstances. However this is (or rather was) my problem: Any backup, detach, restore, transaction-log-fil-size change results in an unidentified error, which SQL tries to log into the transaction log, which is naturally full. I tried growing the trasnaction log, it failed. I tried detaching, it failed. And I could not copy the trans log eventually, because I deleted it :-D The db was royally screwed and it frustrated me that SQL has such an odd and archaic way of handling backups, transaction logs etc. Thanks for the advice though. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
-
Which version of SQL Server are you using? In 7 (if I remember rightly) there is a 'truncated log file' option, and also an auto-truncate option that stops this from being an issue. In 2000 this is set by default. But I'm guessing super-cheerful advice is not gonna help you one little bit at the moment! cheers, Chris Maunder
Chris Maunder wrote: But I'm guessing super-cheerful advice is not gonna help you one little bit at the moment! A good pint or ten would well though :-D Chris Maunder wrote: Which version of SQL Server are you using? In 7 (if I remember rightly) there is a 'truncated log file' option, and also an auto-truncate option that stops this from being an issue. In 2000 this is set by default. I do readily admit that I am to fault for my dB getting trashed. I was frustrated by trying to import a simple Excel file, went a bit dippy, clicked everything and ended up deleting the transaction log, something I now know you should not do. HOWEVER! I do believe that SQL Server has some very odd idiosyncracies in the way it handles backups, restores and transaction logs. I would think we have progressed from "Cannot backup as backup file is locked" or "Restore failed, writing to transaction log, transaction log full, error..." error messages. There has to be a better way than a bunch of mdf and log files hanging around. And why oh why is a transaction log so integral to the structure of a dB? It is a log after all, not a structure file surely? Anyway, I have re-built the dB and it is actually working better now (less tables, less fields, faster, easier to maintain etc.) :-D regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
-
Try Access:-D
Roger Wright wrote: Try Access I could also ditch ASP, go back to CGI and write everything using V in a Unix shell... :rolleyes: Though I do admit, Access is easier to administer. You delete the mdb and it is all your fault. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
-
Roger Wright wrote: Try Access I could also ditch ASP, go back to CGI and write everything using V in a Unix shell... :rolleyes: Though I do admit, Access is easier to administer. You delete the mdb and it is all your fault. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
I was going to suggest Vi in a post earlier about the best editing tool, but the author insisted on color:)
-
Which version of SQL Server are you using? In 7 (if I remember rightly) there is a 'truncated log file' option, and also an auto-truncate option that stops this from being an issue. In 2000 this is set by default. But I'm guessing super-cheerful advice is not gonna help you one little bit at the moment! cheers, Chris Maunder
Chris Maunder wrote: there is a 'truncated log file' But when you full the Log File with a Transaction, this happens not free the space... I had the same problem several times.:mad: :mad: :mad: Paul, you are Welcome to the club of Transaction Log file full boys....:cool: Best Regards Carlos Antollini. Sonork ID 100.10529 cantollini
-
Chris Maunder wrote: But I'm guessing super-cheerful advice is not gonna help you one little bit at the moment! A good pint or ten would well though :-D Chris Maunder wrote: Which version of SQL Server are you using? In 7 (if I remember rightly) there is a 'truncated log file' option, and also an auto-truncate option that stops this from being an issue. In 2000 this is set by default. I do readily admit that I am to fault for my dB getting trashed. I was frustrated by trying to import a simple Excel file, went a bit dippy, clicked everything and ended up deleting the transaction log, something I now know you should not do. HOWEVER! I do believe that SQL Server has some very odd idiosyncracies in the way it handles backups, restores and transaction logs. I would think we have progressed from "Cannot backup as backup file is locked" or "Restore failed, writing to transaction log, transaction log full, error..." error messages. There has to be a better way than a bunch of mdf and log files hanging around. And why oh why is a transaction log so integral to the structure of a dB? It is a log after all, not a structure file surely? Anyway, I have re-built the dB and it is actually working better now (less tables, less fields, faster, easier to maintain etc.) :-D regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
Paul Watson wrote: And why oh why is a transaction log so integral to the structure of a dB? It is a log after all, not a structure file surely? IIRC the transaction log contains exactly what has happened to the database, even if it hasn't happened yet. Which is why its important to the database, something could have happened there but not be reflected in the mdf. Just what I recall anyway, it could be for a different DB system altogether or something my mind made up :-P James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978