vap
Active Member
RE: Importing/Exporting Code
Hi, Mark,
You've already got some responses, but I'll still try to add to them.
There is no better way. There are ways, and you can choose, which is more
comfortable to you.
1. You can copy Central Objects records for your tables. Simplest, fastest,
the most dangerous way. I never used it, because OneWorld is assigning some
internal identifiers to event rules, and I'm afraid you'll never know if
they get in conflict with custom development at the target site.
2. You can create an update package (include specs), then create an .mdb
file, with the same tables, and in the same fashion as JDEdwards ESU (older
ones, never had time to have a look at the new ones). It worked quite fine
on more then a dozen of transfers in B7332 (SP from 7.1 to 11.3). It did
work to an extent from B7332 SP11.3 to XE SP13base, but we had problems with
DSTR objects. If you have translations, you've got to move them separately
(have a look at language DB, which comes on the language CD, it's quite
easy)
3. You can use Packaging Tool. We never could make it work in B7331, it
worked, but with glitches, in B7332, but was a lot more complex then method
2. I had a colleague of mine try it in XE - he told me that it worked like
magic and everything went fine, but when I asked him, where did he install
it - and he answered that he did not...
.
4. You can try to use those third party tools, but I would exercise extreme
care - they most probably do copy Central Objects records, and JDEdwards
does not do it for a reason (yes, I sometimes hate RL, but we all must give
them a credit - OW is a fine product, almost as fine as World ). One
thing you MUST verify, is that they tested the tool at your release level
and SP level.
5. If you have no custom development on the target site or plenty of disk
space - you can just take over the whole Central Objects DB, restore it
either to Central Objects of Development Environment, or restore it to
another environment and use Object Transfer
6. There is an old fashioned way - our programmers love it as much as I have
it (I had to use it for 100+ objects one time): On target site, on a
development machine, you create an object with the same name (take care of
DD items and such), make sure that OL thinks the object is checked-out to
this machine, then exit OneWorld and substitute the DEV733 specs folder with
directory you brought from development machine on the source site (prior to
collecting the directory, you've got to make sure that all objects are
installed locally), then you go in OneWorld and check in all these objects.
It worked fine (better then any other way, including method 2) in B733,
B7331 (I don't remember SP levels, we used several at that time), B7332 from
SP7.1 to 11.3
You can use all of the above recommendations, at your own risk and not
blaming me, when you crash your client site in the middle of a busy-season.
Regards,
Vladimir Ponomarev
Hi, Mark,
You've already got some responses, but I'll still try to add to them.
There is no better way. There are ways, and you can choose, which is more
comfortable to you.
1. You can copy Central Objects records for your tables. Simplest, fastest,
the most dangerous way. I never used it, because OneWorld is assigning some
internal identifiers to event rules, and I'm afraid you'll never know if
they get in conflict with custom development at the target site.
2. You can create an update package (include specs), then create an .mdb
file, with the same tables, and in the same fashion as JDEdwards ESU (older
ones, never had time to have a look at the new ones). It worked quite fine
on more then a dozen of transfers in B7332 (SP from 7.1 to 11.3). It did
work to an extent from B7332 SP11.3 to XE SP13base, but we had problems with
DSTR objects. If you have translations, you've got to move them separately
(have a look at language DB, which comes on the language CD, it's quite
easy)
3. You can use Packaging Tool. We never could make it work in B7331, it
worked, but with glitches, in B7332, but was a lot more complex then method
2. I had a colleague of mine try it in XE - he told me that it worked like
magic and everything went fine, but when I asked him, where did he install
it - and he answered that he did not...
.4. You can try to use those third party tools, but I would exercise extreme
care - they most probably do copy Central Objects records, and JDEdwards
does not do it for a reason (yes, I sometimes hate RL, but we all must give
them a credit - OW is a fine product, almost as fine as World
). Onething you MUST verify, is that they tested the tool at your release level
and SP level.
5. If you have no custom development on the target site or plenty of disk
space - you can just take over the whole Central Objects DB, restore it
either to Central Objects of Development Environment, or restore it to
another environment and use Object Transfer
6. There is an old fashioned way - our programmers love it as much as I have
it (I had to use it for 100+ objects one time): On target site, on a
development machine, you create an object with the same name (take care of
DD items and such), make sure that OL thinks the object is checked-out to
this machine, then exit OneWorld and substitute the DEV733 specs folder with
directory you brought from development machine on the source site (prior to
collecting the directory, you've got to make sure that all objects are
installed locally), then you go in OneWorld and check in all these objects.
It worked fine (better then any other way, including method 2) in B733,
B7331 (I don't remember SP levels, we used several at that time), B7332 from
SP7.1 to 11.3
You can use all of the above recommendations, at your own risk and not
blaming me, when you crash your client site in the middle of a busy-season.
Regards,
Vladimir Ponomarev
