Forum Replies Created
-
AuthorPosts
-
peterlaursen
ParticipantThanks for your feedback!
can you tell if you use COMMUNITY or ENTERPRISE version?
November 19, 2007 at 9:12 am in reply to: Filling Insert Row With Values From A Displayed Row #25042peterlaursen
ParticipantOK .. something like a spreadsheet 'autofill' thing then?!
peterlaursen
ParticipantHere is an example using dual column PK that works (with 'manange relationships' and Schema Designer):
/*normal construction*/
CREATE TABLE `parent` (
`id` bigint(20) NOT NULL auto_increment,
`t1` varchar(20) NOT NULL,
`t2` varchar(20) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `t1` (`t1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `child` (
`id` bigint(20) NOT NULL auto_increment,
`t1_child` varchar(20) NOT NULL,
PRIMARY KEY (`id`),
KEY `t1_child` (`t1_child`),
CONSTRAINT `FK_child` FOREIGN KEY (`t1_child`) REFERENCES `parent`(`t1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/* cleaning up*/
DROP TABLE child;
DROP TABLE parent;
/* dual colunm PK in target */
CREATE TABLE `parent` (
`id` bigint(20) NOT NULL auto_increment,
`t1` varchar(20) NOT NULL,
`t2` varchar(20) NOT NULL,
PRIMARY KEY (`id`,`t1`),
UNIQUE KEY `t1` (`t1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `child` (
`id` bigint(20) NOT NULL auto_increment,
`t1_child` varchar(20) NOT NULL,
PRIMARY KEY (`id`),
KEY `t1_child` (`t1_child`),
CONSTRAINT `FK_child` FOREIGN KEY (`t1_child`) REFERENCES `parent`(`t1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/* we try to provoke an error */
ALTER TABLE `child` DROP FOREIGN KEY `FK_child` ;
ALTER TABLE `child` add constraint `FK_child` FOREIGN KEY (`t1_child`) REFERENCES `parent` (`t1`)
[attachment=783:expected.jpg]
Seems that we have two issues here:
1)
In your example there are two FK's from each their table referencing two different columns that together constitute this 'dual column' PK in the same
table. This seems to 'fool' the Schema Designer 2)
In my example the 'manage relationships' dialogue gets fooled by a specific key setup.
peterlaursen
ParticipantBut there seems to be introduced a bug in 'Manage relationships' dialogue recently (while developing Schema Designer?)
After execute those create stmts:
CREATE TABLE `parent` (
`id` bigint(20) NOT NULL auto_increment,
`t1` varchar(20) NOT NULL,
`t2` varchar(20) NOT NULL,
PRIMARY KEY (`id`,`t1`),
UNIQUE KEY `t2` (`t2`) — note: this key was added as compared to example above!
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `child` (
`id` bigint(20) NOT NULL auto_increment,
`t1_child` varchar(20) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
The dialogue displays like attached. It is not possible to 'blank' the columns in the target.
How to define a FK from child.t1_child to parent.t2 ?
[attachment=782:fkcreate.jpg]
peterlaursen
Participantedit:
This post was removed. It was a silly mistake only!
— peter
peterlaursen
ParticipantYes!
If the email address we have registered is still available for you, you can do everything yourself.
Just log on to our Customer Portal at
http:/www.webyog.com/CustomerArea
.. and edit details
If it is not available we will have to update the database manually.
In that case (for privacy) create a ticket with details here:
http://www.webyog.com/support/ttx.cgi
.. and we will take care
peterlaursen
Participant1)
desired 'many-one' between tables B/C on Field_2″ becoming 'one-one'
The problem is this (if I understand correctly)
CREATE TABLE `areas` … PRIMARY KEY (`category`,`area`),
There is a primary key defined spanning two rows. Including the row that is referenced in the Foreign Key CONSTRAINT in another table. That is why you get a one-to-one relationsship. Can you tell how that PK with that definition came into existence?
2)
desired 'many-many' between tables A/B on Field_1 becoming 'many-one'
Whether 'one' or 'many' is displayed depends on the type of index existing on a column. To create a many-many the indexes on both columns must be non-unique.
We have a report similar to 1) in our ticket system, so there may be something to be corrected or clarified!
peterlaursen
ParticipantOnce a query has been created the query itself (as SQL) can be saved to a file or a 'favorite'.
Your are right that the canvas and the grid of the query builder cannot be saved. Hoewer you can save a LAYOUT from the Schema Designer. We plan to make it possible for the QB to open a SD layout. This will be a few weeks only before we release.
'reverse engineering' a SELECT statement into a QB grid display is not planned however. This does not necessarily mean that we will never do .. only that currently assigned tasks does not include this.
peterlaursen
ParticipantIn SQLyog COMMUNITY you have an export option in the database and table menu's (and context menu's)-
For instance right-click a database, a dialogue opens where you can select what tables to back up at the bottom.
In SQLyog ENTERPRISE there is a more advanced backup tool (in the 'powertols' menu). This one gives options to divide the backup into a file for every table, use a timestamp for naming the backup file and more.
peterlaursen
ParticipantNow I see the problem!
After reading the exported file into Excel, most rows in the `title`column displays 'binary/image'. We will look into this on Monday.
Now .. if you want to export those data to Excel you can export as 'CSV' instead of 'EXCEL XML'. Select this option, click the 'change' button .. 'fill Excel friendly values' and change the column delimiter from “,” (comma) to “;” (semicolon) if you are running a localized Continental European version of MS-Office.
For the comma/semicolon issue refer to:
http://www.webyog.com/faq/28_73_en.html
“And in most of continental Europe (where the comma is used for decimal notation – ie: “4.123,7” instead of English notation “4,123.7”) it is a de facto convention to use semicolon and not comma!”
peterlaursen
ParticipantYou are right – there is no change in this respect.
I still do not know if we can 'reinstantiate' PLINK if connection is lost between PLINK and he SSH Daemon.
mybe on Monday somebody else can tell if there has been considerations in this. The issue is recorded in our issue-tracker.
peterlaursen
ParticipantYour dump imported creating 515 rows here.
In your first post you write:
“Instead it just shows the datatype (Image/Binary).”
Is this in the SQLyog DATA tab it does so. It does not for me – neither in the `title` or `body` column. Please explain?
BTW: There are some encoding issues with some data. Example like
after import this
Quote:“Now that you mention it doctor…”- Symptom reporting and the need for systematic questioningbecomes
Quote:“Now that you mention it doctor…â€�- Symptom reporting and the need for systematic questioningEdited: Adding “SET NAMES UTF8;” to your dump corrected that!
I think it is a bug with this phpMyAdmin version that it encodes as utf8 (and even inserts utf8 BOM (Byte order Mark) at the beginning) but does not SET NAMES accordingly. Please use SQLyog (or 'mysqldump') for dumping next time you want to post here (unless there is a very special reason not to!).
peterlaursen
ParticipantWe will have to FULLY understand this before deciding what to do!
For some reason you have experienced that sometimes a SJA job runs for very long time (seems like 'running forever'). However this will NOT prevent another SJA job to start. You can have hundreds of SJA jobs running at the same time (provided that the server allows for that number of simultaneous connections).
I think the problem is SSH-tunnelling! A SSH connection starts a PLINK instance. That PLINK instance ocupies a local port. That port will be unavailable as long as this PLINK process has not been closed by its 'parent' SJA process (or explicitly killed by a human user). An attempt to start another job with the same connection settings (including the same local port for SSH) will fail, because the port is not available to the new job.
Can you confirm this is what happens?
Actually I think we should consider to make it possibe specify a port RANGE. Let's says port range 3310-3350 was specified. If connnection fails on 3310 it will next attempt 3311, and next 3312 and so on untill the end of the specified range.
That does not exclude that also a
setting for a SJA job could also be a good idea! peterlaursen
ParticipantPlease verify the fix with 6.14 RC.
peterlaursen
ParticipantPlease try 6.14 RC
-
AuthorPosts