What are the primary differences between TDD and BDD?

I've actually used your first approach with quite some success, but in a slightly different ways that I think would solve some of your problems:

1. Keep the entire schema and scripts for creating it in source control so that anyone can create the current database schema after a check out. In addition, keep sample data in data files that get loaded by part of the build process. As you discover data that causes errors, add it to your sample data to check that errors don't re-emerge.

2. Use a continuous integration server to build the database schema, load the sample data, and run tests. This is how we keep our test database in sync (rebuilding it at every test run). Though this requires that the CI server have access and ownership of its own dedicated database instance, I say that having our db schema built 3 times a day has dramatically helped find errors that probably would not have been found till just before delivery (if not later). I can't say that I rebuild the schema before every commit. Does anybody? With this approach you won't have to (well maybe we should, but its not a big deal if someone forgets).

3. For my group, user input is done at the application level (not db) so this is tested via standard unit tests.

Loading Production Database Copy:
This was the approach that was used at my last job. It was a huge pain cause of a couple of issues:

1. The copy would get out of date from the production version
2. Changes would be made to the copy's schema and wouldn't get propagated to the production systems. At this point we'd have diverging schemas. Not fun.

Mocking Database Server:
We also do this at my current job. After every commit we execute unit tests against the application code that have mock db accessors injected. Then three times a day we execute the full db build described above. I definitely recommend both approaches.

When I started to look at BDD I investigated all the frameworks out there (for .net) and ended up using none of them. Main reason is I feel like the community hasn't settled on a syntax and best practises yet so instead I continued to use NUnit with a base class based on a blog post by Ben Scheirman. This worked out really well because BDD is not about the tooling but making the tests clean and understandable which is totally possible with normal tools like nunit.

Compared to my old unit tests the new style is much more readable and puts a lot more focus on naming and behavior. We're not that far from printing out the method names and have a discussion with the business people about the system.

Some additional reading by Scott Bellware: Behavior-Driven Development

Examle of a test:

public class WhenAddingLineItemToEmptyOrder : BDDBase
{
    Order order;

    [SetUp]
    public void Arrange()
    {
        order = new Order();
    }

    public void Act() // called by BDDBase
    {
        LintItem item = new LineItem();
        item.Quantity = 1;
        item.Price = 10;
        order.AddLineItem(item);
    }

    [Test]
    public void TotalPriceShouldBeUpdated()
    {
        Assert.AreEqual(10, order.TotalPrice);
    }

    [Test]
    public void OrderCanBeCheckedOut()
    {
        Assert.IsTrue(order.CanBeCheckedOut)
    }
}