Home » Developer & Programmer » Forms » "Start In" path for Builder / Runtime, need feedback ...
 "Start In" path for Builder / Runtime, need feedback ... [message #197789] |
Thu, 12 October 2006 13:36  |
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 ...
- in the ORANT\BIN folder (or wherever BIN and the EXEs are)
in the ORANT\BIN folder (or wherever BIN and the EXEs are)
- 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)
- 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 #197965 is a reply to message #197847] |
Fri, 13 October 2006 09:06  |
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 |
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 #198359 is a reply to message #198168] |
Mon, 16 October 2006 15:31 |
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 
|
|
|
|
| Re: "Start In" path for Builder / Runtime, need feedback ... [message #198599 is a reply to message #198359] |
Tue, 17 October 2006 21:55 |
 |
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS 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
|
|
|
|
Goto Forum:
Current Time: Sat Feb 08 17:04:26 CST 2025
|
] 
Blog
Search
Help
Members
Register
Login
Home
