Comments
Sort by recent activity
Furthermore, AUTO_INCREMENT is added to the ALTER TABLE statements. It doesn't make any sense when table data is not even considered in the synchronization. / comments
Furthermore, AUTO_INCREMENT is added to the ALTER TABLE statements. It doesn't make any sense when table data is not even considered in the synchronization.
Michelle Taylor wrote:
While quoting the identifiers makes that particular instance case-sensitive, I believe that you can continue to refer to them in a case-insensitive manner afterwards as long as they remain in all upper case. If this is not how it works then please correct me [image] .
I decided to test and post the results... CREATE TABLE foo (ID NUMBER);
INSERT INTO foo (ID) VALUES (1); -- OK
INSERT INTO "foo" (ID) VALUES (1); -- ERR
INSERT INTO FOO (ID) VALUES (1); -- OK
INSERT INTO "FOO" (ID) VALUES (1); -- OK
CREATE TABLE "foo" (ID NUMBER);
INSERT INTO foo (ID) VALUES (1); -- ERR
INSERT INTO "foo" (ID) VALUES (1); -- OK
INSERT INTO FOO (ID) VALUES (1); -- ERR
INSERT INTO "FOO" (ID) VALUES (1); -- ERR
... but I got lost... Oracle is totally insane. / comments
Michelle Taylor wrote:
While quoting the identifiers makes that particular instance case-sensitive, I believe that you can continue to refer to them in a case-insensitive manner afterwards as lo...
alice.easey wrote:
We've just released our latest early access build.
We've made considerable improvements to the way we're handling constraints and would really appreciate it if you could try out the latest build and let us know what you think.
I need to do more testing (I wish I had the time now...) but a preliminary test shows the new release is working way better. The top panel only displays as modified the objects that were actually modified.
The bottom panel still highlights some differences that are not real because it includes the database name in CREATE TABLE statements but it's a minor issue. / comments
alice.easey wrote:
We've just released our latest early access build.
We've made considerable improvements to the way we're handling constraints and would really appreciate it if you could try o...
Simon C wrote:
Out of interest, what constraint properties are different between your databases (if any)?
I've added a couple of tables so two of the existing tables have new foreign keys. There aren't any other changes related to constraints.
(All the source code is stored in versioned text files so I can compare with any file differencing tool.) / comments
Simon C wrote:
Out of interest, what constraint properties are different between your databases (if any)?
I've added a couple of tables so two of the existing tables have new foreign keys. The...
Simon C wrote:
Could you give an example of the sync script it generates going the wrong way, with the differences it should be syncing?
The sync process itself is fine, sorry if I made you think it's not.
My concern was about the way it's expressed with words and icons. I had the mental image that you pick the source database, apply some changes to it and obtain the target database:
SOURCE => TARGET
(Or, in another words, FROM => TO.)
However, as you have just described, the program does the opposite: it applies changes to TARGET so it becomes SOURCE. And it represents it with the same left-to-right arrows:
SOURCE => TARGET
Perhaps I'm confused by the concept of CHANGESET used by version control tools. This is the first (functional) database compare program I ever use. / comments
Simon C wrote:
Could you give an example of the sync script it generates going the wrong way, with the differences it should be syncing?
The sync process itself is fine, sorry if I made you th...