Home » Developer & Programmer » Forms » "Start In" path for Builder / Runtime, need feedback ...
icon5.gif  "Start In" path for Builder / Runtime, need feedback ... [message #197789] Thu, 12 October 2006 13:36 Go to next message
sumiche
Messages: 5
Registered: October 2006
Location: New York, NY
Junior Member
Every Windows shortcut you create has a "Start In" folder to specify (or not) depending on the needs of the program you want to run. In the case of Oracle Forms (at least, thru 6i), there are several places one can start ...

  1. in the ORANT\BIN folder (or wherever BIN and the EXEs are) in the ORANT\BIN folder (or wherever BIN and the EXEs are)
  2. in the folder where the FMB / FMX files reside (FMB being what IFBLD60.EXE reads / writes, FMX being the compiled version created by the builder, run-able with IFRUN60.EXE) (if users share a common application / set of FMX files, they may be running these via locally installed Forms Runtime, with a drive mapped to the server)
  3. in some other folder for some reason, e.g., ORANT\FORMS60 (primarily a local folder, but it could be a network folder)
For forms, running from BIN locates the process close to the EXEs and DLLs that forms needs. Running from the FMX folder guarantees you're close to your PLLs (if you've created them ... a good practice is to compile with paths removed, and keep the PLLs and FMXs in the same folder).

Wherever you run from, if Forms / Reports / SQL*Plus is going to create a log file (depending on various other tweaky settings), it _seems_ to create it in that "start in" folder.

My question is this ... is A, B, or C better, and under what circumstances, or how is case to be made for one or other settings ... OR ... do people just ignore this until something goes wrong?

I do know about registry settings for Forms / Reports paths ... and how to use API calls to get registry settings. What I am unclear on is EXACTLY WHERE AND HOW those little log files get specified and saved. I can find / tweak SOME settings, but not others ... some users leave a trail of log files on shared server folders, others do not. I am trying to determine / understand precise wheres / hows.

Thanks for your time, and any clues you may offer.

[Updated on: Thu, 12 October 2006 20:34] by Moderator

Report message to a moderator

Re: "Start In" path for Builder / Runtime, need feedback ... [message #197847 is a reply to message #197789] Thu, 12 October 2006 20:47 Go to previous messageGo to next message
djmartin
Messages: 10180
Registered: March 2005
Location: Canberra ACT Australia
Senior Member
Account Moderator
Always use 'B'.

Both options A and C means putting user files into a software supplier maintained directory. This is a 'no-no' as the software supplier may change the name of the directory during an upgrade, or empty it without verifying its contents. (It is THEIR directory after all.)

You are quite correct in having the PLLs and FMX (and MNX) in the same directory and pointing to it via the 'Start In' slot. This is the ONLY way to get the Form Builder Debug facility to automatically retrieve a form that is invoked from the form currently running in the Builder.

When it comes to log files, remember that when using 'text_io' etc you need to have defined these directories in the UTL_FILE_DIR of the 'init.ora' or its equivalent.

David
Re: "Start In" path for Builder / Runtime, need feedback ... [message #197965 is a reply to message #197847] Fri, 13 October 2006 09:06 Go to previous messageGo to next message
sumiche
Messages: 5
Registered: October 2006
Location: New York, NY
Junior Member
Thanks, David, for the speedy reply!

I agree with your reasoning, as to the "A" folders being owned by a company (and possibly the "C" folders as well) ... however, I disagree with the "always" part ... what follows is my rationale, but there is one caveat ... the only thing I'm talking about putting in the "company" folders are the log-type files created when things compile or run. Any of my own code I do not keep there for the reason you state: they're not my folders. But I see the log stuff as throwaways, good once, good for occasional tracking, but 99% useless.

... my argument to "my" dev group follows ...
(also, we are a WinXP shop, altho' our DBs are on a Unix box ... we don't write out to the Unix OS environ, it's all done on PC side ... and, in case here, am talking about what the Form/Reports programs do of themselves, based on either local config files or config registry settings, not something that to my knowledge would be accessible to UTL_FILE)

------------
I make the case for a LOCAL (that is, ORANT\BIN) setting for the following reasons ...

(1) -- these files are of only marginal use _to_us_ (this may not be the case for all users, nor the case for a large developer community), and, in any case, are of use to just one person at a time, thus it is EASIER to trace your own issues, without interference from anyone else's issues, if the files are kept locally. The important thing is to know where to expect to find one's log files.

(2) -- given the sometimes oddly precarious nature of network traffic here, the less written to a network drive, the better, the less interference the logging application (SQLplus, Forms, Reports (if I could stop SQRibe from doing it, I would)) has to handle (the local drive should give no interference, since the program is compiling locally as well)).

(3) -- I have always run stuff with local startup paths -- now I know I don't do as much compiling as you or Grace (even with my old computer, when I had less memory than y'all) -- I don't seem to have had near the traffic / speed issues you all have talked about -- where log files get written is of interest when one is trying to tune a local PC's network interactions.

(4) -- since all our paths are in the registry, and we don't work in folders that are not pathed there, there is no particular advantage to having the start up folder as a network location, but there is detriment (because of the network issue).

If (3) wasn't true and (1) was of value, I would say fine. But these do not outweigh (2) in my mind.
----------
Is my reasoning out of whack?

Thanks again for your time.
Re: "Start In" path for Builder / Runtime, need feedback ... [message #197967 is a reply to message #197847] Fri, 13 October 2006 09:11 Go to previous messageGo to next message
sumiche
Messages: 5
Registered: October 2006
Location: New York, NY
Junior Member
Missed something in my first reply ...

Is it the case the Forms Debug will not run correctly, unless pointed to where FMB/FMX application pairs sit?

If our users are just using Forms Runtime, does it matter where the "Start In" folder points, since we wouldn't be debugging from there?

Thanks again.
Re: "Start In" path for Builder / Runtime, need feedback ... [message #198168 is a reply to message #197967] Sun, 15 October 2006 23:35 Go to previous messageGo to next message
djmartin
Messages: 10180
Registered: March 2005
Location: Canberra ACT Australia
Senior Member
Account Moderator
I don't feel inclined to refute your 4 point argument.

In many organisations there are PC 'POLICY' conditions that do not permit 'users' to write to the directories that contain the executibles (which may be on a network drive) or the Oracle binaries (which may also live on a network drive). ALL users MUST have the 'TMP' and 'TEMP' environment variables defined and they MUST point to a drive to which the 'user' has access. In this situation the 'user' should have their shortcut point to this 'temporary' directory. The people who should have their shortcut pointing to the SOURCE FMB files are the 'developers'.

David
Re: "Start In" path for Builder / Runtime, need feedback ... [message #198359 is a reply to message #198168] Mon, 16 October 2006 15:31 Go to previous messageGo to next message
sumiche
Messages: 5
Registered: October 2006
Location: New York, NY
Junior Member
Hmm, I'm stuck now, David. I'm trying to understand whether my logic is OK. You say "start up in the FMB directories" and I am saying, why? Just to keep the log files there? Is there some other reason? I really am trying to understand "why" ... in case there's some hidden 'gotcha' that will be visible to users or developers given the right condition(s) / combination(s).

I have been config'g software and developing DBs for 20+ years, and generally I find there's a reason for something (e.g., if ya don't defrag yer hard drive occasionally, and clean out yer temp folder and large files, Windows will sometimes toss in its cookies for no apparent reason -- when really something tipped memory over the edge from management into misalignment ... give it no edge to tip over, and you're ahead of the game). One of my favorite sayings is "It's just as easy to paint yourself into a corner in a large house as in a small one, it just takes longer."

In my book, all unnecessary net traffic is bad, and writing these log files is ... unnecessary. I control my local environ as tightly as I can, _I_ am a policy setter with respect to what goes where on whose PC and why. In the case of "my" group ... we're way small, and I don't worry about "deleting an executable" -- I trust my staff or I wouldn't have taken them on. In the case of my users, they cannot touch the executable locations, thus can delete nothing (I can see their log trail tho', if I want to). TMP / TEMP is also covered. The users themselves are currently running via MS Terminal Server, while we developers are working in plain ol' client/server mode.

So ... I'm trying to understand what real benefit or loss is gained by what setting. If one can't run debugger, that may be a detriment. If one never has run debugger or doesn't care, hey, caveat emptor. When I tell my users "do it this way because it's better" they nearly always ask why ... if the answer is "because it breaks otherwise" ... that's OK. But ... so far as I can tell, that's not the answer here. And our network traffic is so bad sometimes (not usually, but ...), that a user will do a query, change some data, click save, and ... <poof> their connection blinked so they have to do it again (Windows may reconnect to the net OK in the background, but that's not always true for the DB connection) ... thus, sometimes even a small thing is a good thing. So I'm wondering, for Forms, where that "Start In" path really weighs in.

Thanks for your time.

SM Cool
Re: "Start In" path for Builder / Runtime, need feedback ... [message #198599 is a reply to message #198359] Tue, 17 October 2006 21:55 Go to previous message
djmartin
Messages: 10180
Registered: March 2005
Location: Canberra ACT Australia
Senior Member
Account Moderator
Suzanne,

Sorry if my previous reply was a little 'short'. Most of the people posting on this site are students or low experience level newbies. As you are a 'newbie' (to this forum) I had categorised you as one of the latter. My error. My apologies.

When I read your original post I noted that you are running Forms 6i and assumed that you were running 3-tier. Now that you have clarified your environment to be client/server using MS Terminal Server and with multiple users - I had assumed that you were trying to run Forms 6i only on your PC and needed the extra information for setting up a 'subordinate' user accessing your PC for 'proof of use' - the situation is quite different. You could still have the users accessing a common write area on the server box but it is just as easy to give them read-only access to the executable files but write access to the directory so that they can have their log files there. How do you give them each a differently named file into which to write?

As the development and user areas will be quite different, probable different machines or directory structures, and also the access levels for the developers and users being different, having the both using the executable store as their 'start in' is okay. At one facility, the reason for not giving them 'direct' access to the executables store, was that if we moved it we had to change the shortcut versus just changing the 'PATH' (whether that was the MS PATH or the FORMS60_PATH), and also they would know where it was and they were notorious for trying to run the forms directly instead of by the 'splash' screen (which did most of the security validation and some 'global' value setups). We worked on the principle of "What they didn't know couldn't hurt us."

I hope this extra information has helped resolve any of your outstanding uncertainties.

David
Previous Topic: Calling procedure from Forms is slow
Next Topic: How to passing Records type in ORA_FFI.register_parameter ?
Goto Forum:
  


Current Time: Sat Dec 03 16:07:50 CST 2016

Total time taken to generate the page: 0.19893 seconds