[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]
==== Using RDK & check-out/check-in : queries (OpenInsight Specific) ====
=== At 25 JUN 1998 02:07:58AM Giles Wycherley wrote: ===
{{tag>"OpenInsight Specific"}}
Basically, the company I work for is about to embark on a large scale conversion from AREV to OI. This is a fairly lengthy topic, so I'll ask a couple of more specific questions first in the hope of some quick answers. If anyone wants to read on after that and give me some further advice, any would be appreciated.
1) If I have an application that contains inherited entities is it in any way possible to edit those entities from within that application or must I be within the source application?
2) I have noticed that once I create a pointer entity in an application I cannot delete it because it is an inherited entity and no modifications can be made to it. I assume that this has something to do with me not being the author of the original entity and not being in the source application. I want to beable to delete the entity in my current application without disrupting the one in my source application. Is there anyway of getting around this?
3) At the moment our clients run an AREV application on-site. Our hope is to update that with a Windows version in the near future. This means that they all have pre-existing AREV data, which could be at any location on-site (i.e. different drives, directories). I am aware that you can share data between AREV and OI by simply attaching the relevant tables through the database manager, specifying the location. I expect that in the beginning we will have to do a full system deployment. The question how do I setup the deployment so that it will attach the existing data at the location that it is setup at on-site? What happens if the tables are deployed with the application, but without data? Do I need to deploy without the tables and somehow set up a script that attaches the appropriate location at run-time?
Unfortunately, that's only the start of my topic. What is currently our biggest concern that we want to resolve sooner rather than later is our version control. If someone else has implemented such a system or is considering so, please read on.
What we originally envisioned was a library of programs. This included all the current programs and any previous versions (whether they were actual versions or simply patches). If a client contacts us we want to beable to look at the version that they hold and not just the most recent version. The idea was that you could check out a program for modification, which would lock it so that nobody else could modify it. The program would then get checked back in and create a new copy with the next release number. The old program would still exist in its original form. (Don't confuse the check-in/check-out terminology I used here with the OI function).
Ideally, you would have one repository for the whole library (however, I don't think this would be possible). It might be the case that we need to do an application or an upgrade/module deployment for each set of program modifications! Any thoughts? I can imagine this becoming unwieldy very, very quickly.
The second part of this would be that, to minimise the possibilities of inconsistent program versions we would implement the OI check-in/check-out functions. Suppose for a moment we had a sinlge repository library, we would then require a work space repository for modifications. I'm not that familiar with how the functions work, but could we check-out the item we need and check it in to the work space repository and then check it back into the library? (Actually, that might not work, I would probably need to deploy the new program and I also don't want to modify the library program).
I guess what I am asking is, has anybody done this within the scope of the currently available OI development utilities or does anybody have a pretty good idea of how to do this? If all that I have previously discussed is completely unnecessary and off-the-wall, please tell me (and hopefully provide the answers to all my problems).
I would appreciate any thoughts regarding anything I have covered here, even the smallest detail may help me resolve these issues.
Giles Wycherley
----
=== At 25 JUN 1998 07:11PM Jeff Blinn wrote: ===
[i]1) If I have an application that contains inherited entities is it in any way possible to edit those entities from within that application or must I be within the source application?[/i]
It is possible - however it actually creates a new copy. For example, if you inherit a stored procedure from SYSPROG, and open it up in your own application - the system will allow you to edit/change the procedure, but when you try to save it, you'll get a message indicating that this is an inherited entity - saving it will create a new copy in the current application (which will then be the copy used by that app) - do you want to continue?
[i]2) I have noticed that once I create a pointer entity in an application I cannot delete it because it is an inherited entity and no modifications can be made to it. I assume that this has something to do with me not being the author of the original entity and not being in the source application. I want to beable to delete the entity in my current application without disrupting the one in my source application. Is there anyway of getting around this?[/i]
It is related to not being in the source application - I thought you might be able to delete the 'pointer', but after taking a quick look, I couldn't find a way to actually do that. Although an inherited entity has currentapp*whatever*whatever as the entity ID - I can't find any such record in SYSREPOS - so it seems the repository allows in SYSREPOS records from inherited apps, and labels them with the current app ID. Unless the pointer is stored in another table?? Maybe someone else explain this better.
As for you other questions - I'll let someone who has dealt with that type of deployment answer.
Jeff
----
=== At 25 JUN 1998 11:51PM Giles Wycherley wrote: ===
Thanks for the information, Jeff.
Upon reading the response you gave to my first question, it looked like you hadn't described the correct sequence of events. However, it lead me to take a closer look at what I was doing. I've been dealing with forms NOT stored procedures (in which case the message saying that it is inherited, pops up on the form load, informing me that no changes can be saved). At this point the Save option is disabled, but what is not readily apparent is that the Save As option is not. I can save the form as itself, with no problem (this might be a bug, but it's a handy one).
Giles Wycherley
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=27BF2A2368FBD6528525662E0021B050|View this thread on the forum...]]