But then I very rarely use ERWin for forward engineering - relying on it for reverse engineering in rare circumstances. I guess I'm of the old school - the database should be created by a script of SQL DDL statements. My approach would have been to suck in the Access database into ERWin and then push it out as a SQL Script. From that point forward, I'd use my text tools to modify and maintain the database. Text is much more pliable.

Anyhow, you got the idea. The particular tool is not what I was trying to promote so much as using a modelling tool to transfer the schema from one database to another. So, if there's another tool to do the same job, then at least the idea was correct.

As for ERWin, I think that CA is the antithesis to the concept of innovation. Buy software, stop development on the tools - then milk every last drop from those that got addicted to the tool. Not particularly one of my favorite companies.

There is a real need for a database modelling tool, but unfortunately the market wasn't very kind to the previous owners of ERWin. They were flying high back in the mid 90's with lots of capital to blow. I was involved in one deal where we were trying to get some investment dollars from them - it involved reverse engineering AS/400 databases via RPG. They were also looking at a bunch of Fortran and Cobol reverse engineering programs. In a matter of 6 months it seemed like they went from being ambitious, to mostly maintenance mode. Part of their problem was they spent a lot of money trying to integrate their tool with COM, but between the mismatch of their tool to the environment (modelling objects is much different to modelling entities - rational kicked their buts) and the inherent competition with Microsoft, they just gave up and sold out to CA.

If they had just stuck to database modelling, the tool would have been a whole lot better.