Hello
First of all, I have logged a case at the support but the problem seems difficult to solve so I figure I give it a go here.
The header above is almost the same as another tread posted in May by Julian Lyndon-Smith. But I still have the same problem after following the advise from Richard Banville.
Solaris 10
OE from 10.2B03 to 11.2.1
proutil <database> -C conv1011 fails with error:
OpenEdge Release 11.2.1 as of Thu Apr 25 19:00:58 EDT 2013
You must have your database backed up before running the conversion. (1024)
Have you done this (y/n) ?
y
Existing _Domain-name NSO in _sec-authentication-domain table conflicts with existing _Domain-name NSO.
Existing _Domain-name SSO in _sec-authentication-domain table conflicts with existing _Domain-name SSO.
Conversion is not allowed until DBA corrects these problems.
Please see OpenEdge 11 Release Notes for more information.
Well I have checked the Database Admininstration guide and I don't have any of the issues mentioned. For the _sec-authentication-domain table it says, "no record can exist with the following values in the _Domain-name field: WINDOWS, WINDOWSID, UNIX and UNIXID". We don't have any of those values in that field in that table. We have "AGENT, AS, CLIENT, LOCAL, NSO and SSO".
I have also tried to do the conversion changing user rights, run as root etc. Same error message.
Anyone?
This is telling you that NSO and SSO are also reserved. The release note should be updated.
Thanks for a fast reply.
Ok, reserved, that would explain it of course...but the values NSO and SSO, are not stored in the table after the conversion, but all the other are (WINDOWS, UNIX and so forth, including an empty default user domain).
Would you say that NSO and SSO are for future updates?
I asked around and although the message is telling you SSO and NSO are reserved, they are actually not so there is a bug here somewhere.
The domain case sensitivity changed and this is why this check is being made.
Here's another possibility
You have a doman name "SSO"
Do you also happened to have a domain name "sso" or "Sso" or "SsO" or "ssO"
Or "nso" or "Nso" or "NSo" or "NsO" or "nsO"
Since the case sensitivity change, they would be considered in conflict of eachother.
No, no other records similar to NSO and SSO.
But I have managed to reproduce the problem in a very simple manner:
In version 10.2B03:
1. prodb mydb empty
2. Add a record in _sec-authentication-system - "AFA"
3. Add two records in _sec-authentication-domain - "NSO" (with access code "one") and "SSO" (with access code "two") both with system "AFA".
4. proutil mydb -C truncate bi
In version 11.2.1:
proutil mydb -C conv1011
and then the error (only 1 conflict this time):
OpenEdge Release 11.2.1 as of Thu Apr 25 19:00:58 EDT 2013
You must have your database backed up before running the conversion. (1024)
Have you done this (y/n) ?
y
Existing _Domain-name SSO in _sec-authentication-domain table conflicts with existing _Domain-name SSO.
Conversion is not allowed until DBA corrects these problems.
Please see OpenEdge 11 Release Notes for more information.
I do have a conversation with the EMEA support regarding this, but no progress (!) with them so far.
With this very reproducible case, support should be able to log a bug on your behalf. In the mean time is it possible to delete the conflicting domains, do the conversion then add them back? Obviously you should not need to do this. but just to get you moving forward with your conversion testing...
Yes, that's what I will do to get moving.
However, I did look into it a bit more and found a pattern, sort of...it seems like it has something to do with the initial letter only (??) and the problem occurs if the domain-name consist of only one letter.
In an empty database (version 10.2B) you can load, easiest way possible this .d-file (into _sec-authentication-domain table):
"B" "AFA" "" "383725" "" "" yes "" "" "" "" ""
"C" "AFA" "" "283715" "" "" yes "" "" "" "" ""
then if you try to convert it, it won't work, C is in conflict.
Now if you change B and C to B and A it works fine.
I had to try some combinations....
A works fine
...
B A works fine
B C doesn't work C is in conflict (the second record)
B D works
...
C A works
C B doesn't work C is in conflict (the first record that is)
C D doesn't work D is in conflict (now the second record)
C E doesn't work E is in conflict
C F works
...
and so on.
I have commented on this to EMEA support so I will let them take it from here, but I found it quite interesting.
Thanks for your replies Richard.
Regards
Daniel
Thanks for your efforts in trying to narrow it down.
I did have a few spare cycles this morning so tried your simple steps to reproduce.
I could not reproduce the issue as stated.
I was testing Solaris 64 bit, 102b.03 to 11.2.1
Are you using a special code page or collation or connection parameters?
Are you on Solaris 64 bit or 32 bit?
Solaris 64 bit
Ok, this narrows it down even more.
Yes, we have a swedish installation, which means a swedish version of "empty.db" (and of course the version we use for all our databases).
I tried exactly the same steps as before but instead of prodb mydb empty (which uses the swedish database) i tried prodb mydb "...dlc/prolang/eng/empty". Then the conversion went fine! So it has clearly something to do with this.
Excellent. Please convey that to your support contact and I'm sure they will take it from there.
Yes, I will.
Thanks again.