Web Version from 8.96 to 8.98

Hello there

I tried to deploy web version but no luck.
Here what i am doing:

1. create simple OMW project
2. bring the version from category <Object librarian> Search type <Objet Name|version name>

\

when i assembly the objects in the object component i can not see my OMW project using Browe object but i can see in browse OMW status. but when i finish deployment can not see the version. This means i have to deploy object along with web version?

Thanks
AD

8.98
8.12

Hi,

You don't have to deploy Web versions.

I heard existing web version needs to be deploy in new release 8.98 Anyways if not then my question is:

I have a web version in PD which was web version in release 8.96, in PD it is working fine. but when i try to create in DV environmnet it says it is already exists infact when i do BV and dont see that version. Looks like i thave to do something in fat client?

Please advice

Thanks
AD

The situation is that with your new Tools Release 8.98, web-only versions are no longer necessary. However, for 8.12 you must install ESU JK17733. You also have to convert your existing web-only versions so that they become "normal" batch versions.

More details here: Oracle Doc ID 626576.1.

Hi Wong,

You awesome you always give good comments and references.

I did copy the windows version from PD to DV (only 1 item to test) in SQL behind the scene and everything looking fine to me. I even dont need to deploy the object.
Is it good way to do?

Thanks
AD

I'm pretty sure that Oracle doc had links to the proper way to convert web-only versions to normal batch versions.

If you didn't have to build a package and deploy it, then there is something missing in your process. It may not show on the screen (because I think the field isn't even there on the form any more), but I believe the field in the Versions table (F983051, VRVCC2) would still be populated. If so, then you haven't really done it the "right" way.

Ok Leave it web version for now

If i have normal batch version in DV and simple if i copy that version in PY envirnment using SQL then i am very positive we dont need to deploy object. As i tried and working fine for me. Do you thing this is not ok for even normal batch version ?


Thanks
AD

Definetly not ok, escpecialy if there are RDA or ER overrides on the version itself. Why wouldn't you do it through OMW, which copies the F983051 record from DV to PY anyway? There is more to a batch version than just the one record in the versions table.

In 8.98.something.... when you create a web version, "shouldn't" 'the process' replicate that version into a specific project - so it can be promoted through all environments?

Maybe I misunderstood the enhancements to the new process - but, I overhead that new (web created) version get placed into a default project for promotion across environments.

Maybe I'm just missing some coherency?

(db)

Let me add some emphasis to what cncjunior said. Now think about this a little. You want to move versions between path codes by using SQL to move the records between F983051 tables. That means you have to consider:

1) If someone updated a version in one environment, and you use this method to "promote" it, you will have to remember to delete the existing record in the other environment first before doing your insert.

2) Your method does not take into account who may have the version checked out, and from which environment. You would have to check this, also by using SQL. Otherwise, you would destroy the check out and check in statuses if you did not watch for this flag. Nobody would know who had properly checked out the version, and from where.

3) Your method does not take into account who has the token, and whether or not the token should be dropped. This information is not in the F983051 table.

4) As cncjunior said, you are not taking into account any version overrides. This information is in the Central Objects (F98760-F98762), not in F983051.

5) Do you really think it is easier for you to do all of these tasks through SQL query manipulation? OMW exists for a reason. The original reason was to enforce some discipline in object check-out and check-in so people wouldn't step on each other. It has evolved somewhat from that point, but that is still its main job. What would be your reason for manually taking over something which OMW does quite well?

OMW has been around for almost 12 years now. I, for one, would really NOT like to return to the previous state where multiple people could have things checked out from different path codes, and whoever checked it in last would win.

Thanks everyone for the impact and feedback.
I did the way you wanted. I learn alot in this process specially the tables involved.

Thanks
AD