Not just using the transaction log, no. It records redo, but not undo, so you can only roll forwards from a point in time, which is the time of a backup. It may be possible to replay the entire log from the start on a blank database, but I don't know you'd "tell" SQL Server that you wanted to do that, even creating a database "for load" probably wouldn't allow it...
Seeing that the recovery model is set to simple and msdn states that the simple recovery model does not support point-in-time recovery - Does this mean that I won't be able to use my transaction log backups to restore the database in a disaster to an hour before it happened?
Even taking a transaction log backup is not supported for databases using the SIMPLE recovery model. This is a restriction of the database engine based on how this recovery model works, and the recovery features it doesn't support, as you mentioned.
A transaction log backup maintenance plan task automatically skips databases in SIMPLE recovery to avoid causing errors.
Which backup should be done first, the database backup or the transaction log backups? Articles that I'm busy reading say I should do the database backup first and then the transaction log backup else I will get maintenance plan errors, but I'm currently first backing up my transaction logs and then data databases and I'm not getting any errors.
For the reasons I mentioned above, it won't matter for databases using SIMPLE recovery, as they will be skipped by the transaction log backup task.
For databases in the other two recovery models, a full backup must exist before you start taking transaction log backups (just the first time), or you will get an error -- this is probably what the articles refer to.
Point-in-time recovery ability is normally driven by business need -- in other words, you determine how critical the data is and how much you can afford to lose, then set the appropriate recovery model to meet those needs, and finally create a backup solution.
Even though SIMPLE recovery does not support point-in-time recovery, if an hour of data loss is okay, perhaps a differential backup solution could work for you. (There are far too many variables that go into developing this kind of solution to give you a complete picture with what was provided in the question.)
Best Answer
Point in time recovery is the concept that a particular set of data can be restored to an exact point in time, rather than just to the time of the last backup file.
In this case with SQL Server, log backups are the usual mechanism for accomplishing this to ensure database consistency.
FULL or BULK recovery modes must be utilised to allow for point in time restore, with the BULK option minimizing the amount of log space needed for certain operations (CREATE INDEX, SELECT INTO, BULK INSERT...). If any of these mechanisms are used, the ability to restore to a point in time using a log backup is dropped, forcing you to restore to before / after the bulk logged operation, for that individual log backup. For more information on this see SQL Server Recovery Models. The reason for this is that the bulk-logged model utilising minimal-logging will not log the data pages to the log file during bulk-logged operations - it will only log the extents that have been changed. Whether you want to use BULK recovery model or not will depend on your individual circumstances and whether you can afford to drop the point in time restores in favour of potentially faster bulk logged operations.
Other than that, FULL recovery model will support your use case.