I am having 2 issues with the oecgi2.exe (BTW - thanks Paul S. for your time and help yesterday).

If I have a table that is not under the oi root directory (it is extremely large and they wanted it on it's on disk/controller) and the oengine that the oecgi2 spawns does not always see this table. I have tried stopping and starting the oengine service but the table is still not acknowledged (it works fine in the application). My work around has been to add "Attach_Table" to my INET routine.

Also, there is another issue that is causing the oecgi2 combined with the onegine server to time out, it is that the spawned oengine is not recognizing all DICT items in a table when my INET procedure uses an xlate.

To confirm this I wrote the following INET.

Function [/color][/size]INET_XLATE_FIELD[/color][/size]([/size]Request[/size]) 
[/size]Declare Function [/color]Inet_QueryParam,Inet_Msg, 
[/color] 
[/color]Equ [/color]CR [/color][/size]to Char[/color][/size]([/color]13[/color]) 
[/color]Equ [/color]LF [/color][/size]to Char[/color][/size]([/color]10[/color]) 
[/color]Equ [/color]CRLF$ [/color]to [/color]CR[/color][/size]:[/size]LF 
[/size] 
[/color]Convert @Lower_Case to @Upper_Case in [/color][/size]Request 
[/color][/size] 
RecKey [/color]=Inet_QueryParam([/size]Request[/size],[/size]"RECKEY"[/color]) 
[/color]Table  [/size]=Inet_QueryParam([/size]Request[/size],[/size]"TABLE"[/color]) 
Field  =Inet_QueryParam([/color]Request[/size],[/size]"FIELD"[/color]) 
[/color] 
[/color]Val [/size]= xLate([/size]Table[/size],[/size]RecKey[/size],Field,[/size]"X"[/color]) 
[/color] 
[/color]Swap @FM with [/color]CRLF$ [/color]in [/color]Val 
[/color][/size] 
[/color]RETURN [/color][/size]Val[/color][/size][/color][/size]         
               

This routine works great on some fields and returns the correct value. On others I get.. Cannot process query: /myWEB/OECGI2.EXE/INET_XLATE_FIELD?TABLE=MYTABLE&RECKEY=00000&FIELD=ANYFIELD

and other times it will time out and the oecgi2 will stay in memory as well as the oengine. Eventually all 10 oengines are stuck in memory and all requests are denied.

Any insight (no pun) is appreciated.

Details.

OE Version 8.0.8

UD LH Service Version 3.0.0.3

Runtime licenses 500+

IIS V6.0

OECGI2.exe 96kb

EServer Config file is…

configuration file for oesocketserver.jar invocation:

java - jar oesocketserver.jar {-l } {-d {<debuglevel}}

which port to listen on PortNumber=8088 maximum number of sockets connected at any time (0=unlimited)

MaxConnections=0

maximum number of engines to keep in queue (for stateless connections ONLY) MaxEngines=10 time (in minutes) to wait before killing idle engines from queue

IdleTimeout=15

default operating mode: "" - JD3 mode

0 - block mode 1 - character mode

2 - 'stateless' block mode Mode= Encoding option (defaults to 8859_1)

Encoding=UTF8 Control Password option (defaults to WINWIN)

ControlPassword=WINWIN KeepAlive option (defaults to 0) - determines whether dropped, active connections

are kept alive as "zombies" (allowing for reconnecting) or terminated KeepAlive=1

Default values: may be set on per-mode, or overall, basis defaults for mode "" (JD3 mode)

Procedure_=JD3_LISTENER

defaults for mode "0" (block mode) defaults for mode "1" (character mode)

Procedure_1=REVCMD_LISTENER

defaults for mode "2" ('stateless' block mode) overall defaults

default name of application Application= default 'dispatch procedure' to run

Procedure=

default user name UserName= default password

Password=

default engine name Server= default startup flags for engine

StartupFlags=65

default shutdown flags for engine ShutdownFlags=1 </QUOTE> —- === At 05 NOV 2010 11:57AM Jared Bratu wrote: === <QUOTE>Just to confirm, There is a REVPARAM file protecting the data table on the separate partition, right? Does the DBT show the file attached via a UNC, Mapped drive, or local drive? Does the attach table ever fail? I.e. any Get_Status() errors after the attach? </QUOTE> —- === At 05 NOV 2010 11:59AM Bob Carten wrote: === <QUOTE> Is the table attached by a mapped drive? The Oengineserver runs in the context of a user that will not know about mapped drives even if it has right to access the files. A way to test that is to stop the service, run the engineserver on the desktop, for example start a DOS session on the server cd to the oinsight folder SC STOP Oengineserver start java -jar OESocketserver.jar If the queries start working then the issue is the Socketserver service environment. Try attaching the tables via UNC instead of drive letter, save the dbt, restart the socket server service. Hung engines suggest there is a message or a debug. You could make the engines visible by adding StartupFlags=1 ShutdownFlags=1 to the OECGI2 registry settings, setting the service to allow interactions with desktop, then restart the service. After that you will see the OENGINE and any debug message on the server console. Finally, you might want to make a test function that acts like Xlate but gives more information, something like: Open table to f_table then open 'DICT.TABLE' to @dict then @id=reckey read @record from f_table, @id then read dict from @dict, field then ans=calculate(field) end else ans=bad field' end end else ans=no record' end end end else ans=unable to open dict' end end else call get_Status(err) ans=Unable to open table ' : err end return inet_msg(request, ans) </QUOTE> —- === At 05 NOV 2010 12:10PM Bruce Cameron wrote: === <QUOTE>Hi Jared, Yes, there is a revparam. DBT shows the file attached via Mapped drive. Attach table does not ever fail to my knowledge. I will also follow and respond to Bob's post. Thanks </QUOTE> —- === At 05 NOV 2010 12:19PM Bruce Cameron wrote: === <QUOTE>Bob, Mapped drives. I will change to UNC over the weekend. I previously did set the service to "interact with the desktop" and did not manage to go into the debugger. The curious thing about the DICT issue is that I am talking about absolute fields. It will recognize NAME, but then another good one, CONTRIBUTION it does not. At first I thought it was just symbolics and followed the trail to the above mentioned table issue but then came across another issue unrelated to that and started poking around some more. I ran your routine and got this message back: Empty message BTW - folks will need to change open 'DICT.TABLE' to 'DICT.':Table and there is an extra END in the code. </QUOTE> —- === At 05 NOV 2010 12:28PM Bruce Cameron wrote: === <QUOTE>Bob, When you say… You could make the engines visible by adding StartupFlags=1 ShutdownFlags=1 to the OECGI2 registry settings, setting the service to allow interactions with desktop, then restart the service. After that you will see the OENGINE and any debug message on the server console. Do you mean to add the registry as a new DWORD or do you mean change the "StartupFlags=65" line in the eServer.cfg file to be 1? </QUOTE> —- === At 05 NOV 2010 03:01PM Richard Bright wrote: === <QUOTE>Bruce, I take it that Bob is asking you to change the parameters in the Registry that appies to oecgi32 ie Windows Registry Editor Version 5.00 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RevSoft\OECGI2 "ApplicationName"=EXAMPLES" "EngineName"=" "FileMode"=1" "FilePath"=" "OILocation"=" "ProcedureName"=RUN_OECGI_REQUEST" "ServerPort"=8088" "ServerURL"=localhost" "ShutdownFlags"=1" "StartupFlags"=1" "SysDownPage"=" "UserName"=EXAMPLES" "UserPassword"=" </QUOTE> —- === At 05 NOV 2010 03:15PM Mark Glicksman wrote: === <QUOTE>It's been my experience that every inet procedure needs to attach tables. I just call another procedure that does the attaching. It doesn't seem to slow things down. </QUOTE> —- === At 05 NOV 2010 03:29PM Bob Carten wrote: === <QUOTE> Thanks Richard, that is indeed what I meant. These are my old a href=https://docs.google.com/Doc?docid=0AX2cDbLL-miwZGhoOXp0bnhfNTVrOXczOXJoZg&hl=en]Notes on OECGI2 Debugging I think the same information is in the formal documentation by now. - Bob </QUOTE> —- === At 05 NOV 2010 03:49PM Jared Bratu wrote: === <QUOTE>The OEngineServer service runs the OpenInsight code to satisfy OECGI requests. Since the service may be running under a different user account the mapped drive might not be mapped. Using a UNC in the database manager or using the attach_table command are the two supported methods. </QUOTE> View this thread on the Works forum...