.. the current design is most intuitive. As per your proposal user would manually need to 'refresh' and I think it would be an annoyance!
However I realize that with big and remote tables it may not always be the case.
Should we include an uption 'not to auto-update data area' when 'something' is selected in Object Browser? (I am not sure how easy that would be however!)
“create view myview as select myfunction(..) as mycol”
then the script will not restore because the function is not created vhen the view should be created. I only see the solution to have 2 dumps so that the function gets created in 1st dump and the view in 2nd.
I think you should test as soon as possible with the software. If not the discussion will be rather abstract.
Now, I would assume that the table-structure of the two apps are so much different that data from more than one table onwill have to go into every table. So you will need the option to 'specify a query' from the first screen of the migration wizard.
like “select tab1.a as new1, tab1.b as new2, tab2.x as new3, tab2.y as new4 from tab1, tab2”
Also you will be able to use 'notifications service' to execute a maitenaince query after the import
I am sorry, but I do not have the slightest idea of what you are talking about!
Do not expect us to know everyone of *.10.000's applications for MySQL – like 'PostNuke' and 'Joomla'!
My best intuition tells me the answer that with the 'Migration Tool' you will be able to generate a job file that migrates one database to another and changes mapping/column definitions accordingly!
We do not use any kind kind of 'activation' model nor locks the registration details to specific hardware in other ways.
If you have a binary/installer and corresponding registration details you can register on another computer as you like – but we request of course that you only have/use the # of installations as per your license!.
I think the comparison with Windows Explorer does not quite 'hold water'. SQLyog is a database client and will need to communicate with the server whenever something happens at the client side. In this case we send a USE statement.
We will disucss this, but could you consider having two different connections with each of the databases specified for one connection?
As regards the issue with the 'manage relationships' dialogue it is per design – only I became confused! The dialogue will display columns defined as FK. You can remove either by selecting it and pressing . However we will consider how to improve intuity in this respect!
1) zoom request has been asked a few times before allready. Current design does not allow for it. It will take some time!
Basically the canvas currently is coded with pure win32 API coding (nothing like ActiveX or OpenGL for instance). Fundamentally it will require some kind of 'graphics layer' and a graphics processor of some kind.
2) Can you explain why this is important?
3)
— > more beautiful … again you will need to detail what you do not like as of now!
— > printable. Currently you can use a screengrabber. There are several that will let you capture a 'sub-window' (example: snag-it). We plan to implement 'save layout as graphics' soon.