secretGeek.netGripping Reading, All The Way Through!
Your system throws up an error message. It's tempting to read the first few words and jump to a conclusion. 'Oh I know what that is...' But you really have to read the entire error message. Often the best bit isn't until the very end.
Error messages are not like those predictable hollywood films that you can walk out of before the end, and still know exactly how it finished up. "Oh yeh, they defused the bomb, he got the girl and the dog learnt a new trick."
Here's two messages I had yesterday:
Could not open new database 'C:\{...Path to Database..}\DATABASENAME.MDF'. CREATE DATABASE is aborted.
An attempt to attach an auto-named database for file C:\{...Path to Database..}\DATABASENAME.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
File activation failure. The physical file name "C:\{...Path to Database..}\DATABASENAME_log.ldf" may be incorrect.
The log cannot be rebuilt when the primary file is read-only.In this case, those last few words pinpointed the exact cause of the problem.
Not long after that, I got this message:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Exclusive access could not be obtained because the database is in use.Again, it was the final words that pinpointed the problem.
It's so easy to read the first few words and start making assumptions. In the first example the assumptions might be "oh, i must have the wrong name for the log file". In the second case the wrong assumption is "oh, the query is taking too long and needs to be 'optimised'..."
I've said before that you have to read the error messages. I'll add now that you have to read the entire error message.
(names of databases have been changed to protect the data)
Next → ← PreviousMy book "Choose Your First Product" is available now.
It gives you 4 easy steps to find and validate a humble product idea.