In the past, I've designed databases using diagrams where each table is a box, listing the column names & types. Now I have a proper DB design tool and I have a choice of ER and ORM diagrams... but after reading Wikipedia's entries on them I'm still confused about what the difference is and which I should be using. In my tool (Visual Paradigm Database Architect) the diagrams even look very similar. In my mind, a DB design diagram has boxes for tables, and the lines joining tables are basically describing how columns in one table take values which are ids from another table... i.e the lines mostly represent foreign keys. Is this how other people view things? And is this an ERD as I always thought, or an ORM diagram?

These diagrams don't refer to foreign keys and IDs - those are implementation details. The diagrams refer to how the objects relate, and yes, that is typically implemented as ids and foreign keys. But it would usually be trivial to implement such a diagram in C++ with pointers and vectors, working from the same notation.

Basically the 2 diagram types seem to do the same thing, except the ORM notation seems more focused on an object's role, so rather than have lines which can start to get a bit ambiguous, you have a variety of boxes and lines from them that denote an object's role with regards to another object. I'd just pick whichever one you're most comfortable with and check that it conveys the information you need.