SQL Power Software Forum

Jeff wrote:I think the best that can be done with the current version is to modify the SQL script that the Forward Engineering feature generates so that the storage engine setting is included.

I just fell into this issue today.

I'm not sure if it's my design philosophy, but this would be a major burden as I forward engineer quite frequently. So, going through the code and changing all tables to be of InnoDB format everytime I forward engineer seems counter productive.

This brings a few questions to mind:

1. Should this tool get you started and once you've pushed to the db platform, you're supposed to close this app and use other tools to complete the job?
2. Or is this tool supposed to be used to reverse/forward engineer a database as many time as wanted during the editing process?

If it's #2, then not keeping the table format seems like a major shortfall?

I'm on the community version ATM and love it's capabilities so far.

Dammit. I figured it out. Seems I had the pk field checkbox checked for the job_id field.

No more problems...

Here's my layout:

I can't seem to be able to stop the job_id field from becoming part of the relationship in Gadget_People. I'll choose either identifying relationship and it still happens.

Gadget_People should only have two fields: gadget_id and people_id enabling People to have multiple gadgets assigned to them.

Trying out PostgreSQL and PA...