When running on Win2000/NT Terminal Server/Citrix winframe etc.. I need to set @station (rather than it picking up the server's stationid. The SET_STATION can be used to set the station id early on at OE startup, but how could I get the stationid to the SET_STATION proc from a variable I have in 16-bit DLL? Any ideas?

1.) It could be done by passing it as another command line parameter (OENGINE.EXE /AP=… /UN=.. MYPARAM) but how can I get hold of the command line params in SET_STATION?

2.) I wrote a DLL proc to return the stationID. This works fine when run from a stored proc AFTER startup, but during the SET_STATION proc just produces a 'Fatal Engine Error ENG0010'

3.) I can't write it to a file as 10 stations could be trying to write to it at the same time, so I couldn't know who's who.

Any bright ideas?

-

Trevor,

Suddenly realised we also might get this problem with identical @Station ids. We have clients who want to use Terminal Server, and there are a couple of things where our app uses @Station and assumes it's unique.

So I did a search for

("terminal server" or citrix or winframe or metaframe) and station. I found some relevant results. See below.

The author of one of the postings claims he has no problems. Perhaps it's dependent on environment (network protocol, etc).

A couple of postings challenge the need for @Station. E.g, one of the things we use it for is to create a unique file name for each user. But having the file on local disk instead of on the server solves that problem.

One unsolved problem for us is where we use @Station to create a unique SYSLISTS key. Our users can search the database, and we store the current result list temporarily under a name based on @Station.

We might have used @Username instead of @Station, but then the question is how to avoid more than one user logging on the app with the same name. Sounds like a basic kind of functionality for a database system, but I assume one must program it oneself.

What is that SET_STATION you mention? Do you mean setname.exe (referred to by others)? And do you know what the latter is?

Search results:

Terminal Server and station id's (Michael Moran) You are here

. . Re: Terminal Server and station id's (Steve Smith)

. . . . . . Re: Terminal Server and station id's (Wayne Curzadd)

Same Station ID's using Citrix Metaframe (Neil Davis) You are here

. . Re: Same Station ID's using Citrix Metaframe (Jim Butler)

TERMINAL SERVER (Barry Stevens)

. . Re: TERMINAL SERVER (Marc Radley Social Software Limited)

. . . . Re: TERMINAL SERVER (Barry Stevens) You are here

. . . . . . Re: TERMINAL SERVER (Donald Bakke)

. . . . . . . . Re: TERMINAL SERVER (Barry Stevens)

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

oystein.reigem@hit.uib.no

Home tel/fax: +47 56 14 06 11.

Thanks for your help, actually, I need a password etc for access to those pages which I dont have.

Re Set_STATION

IF you have a stored proc called SET_STATION with two params, the second of which is station then setting this variable will set @STATION! This proc is run on startup, very early on.

Trevor,

One of the Works postings said "PROSOLVE believe they can achieve a proper unique station ID and locking etc."

One other was from Don Bakke and said "In our testing Terminal Server automatically gave unique ID's. This was with the IPX/Advanced Netware driver."

This stuff about Set_Station - is that documented? Looked/searched in vain both the reference and this site.

- Oystein -

Don't know if SET_STATION is documented. I found info about it from this forum etc. Just have a proc like:

FUNCTION Set_Station (Flag, Station)

• @Station will be already set, but let's change it

 Station=TESTING'

 RETURN

END

In our testing, Terminal server will not give a unique @station (used by oe for syslists etc). We'll probably write to a file and read it in, in Set_station for now.

Trevor,

Thanks for the info on SET_STATION.

About problems caused by identical @Station: Silly me. I only thought of problems where one uses @Station explicitly in one's own programming. But as you say also the system's own use of SYSLISTS is problematic, since SYSLISTS row keys are based on @Station.

That is - the keys contain both @Station and @Username, so if one can make sure that at least one of them is unique, that is enough to avoid problems. So if one somehow can assure that all users logged in simultaneously have different user names that would be enough. Of course one can think of applications where it's necessary to be able to log in with the same user name from several workstations at the same time. But for apps where this is not necessary it shouldn't be too difficult to program something at startup that checked if the same user name was already logged on. Lots of developers must have done that already.

- Oystein -

Another old thread!

Just tried a SET_STATION (just trying to set @station to "TESTING") and it didn't work. Maybe because I tried on non-networked single-user OI 4.0.3 development system, as I understand various parts of OI work very differently when no network licence installed.

I tried a SET_STAION is the app and also in SYSPROG - but neither worked.

Can anyone confirm that SET_STATION works on networked copies of OI 3.7.x, 4.0.x and/or 4.1.x?

Thanks.

Richard,

In order for SET_STATION to work you need to call it as described in this link.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don

Many thanks. I didn't pick it up as I searched on SET_STATION in which thread this aspect wasn't covered.

Best wishes

Richard

The link referenced in Don's original post was changed. For current information on @STATION and and SET_STATION please refer to:

http://www.revelation.com/knowledge.nsf/d397fbbab8ac707185256dd600218f18/c4d1a9e486b2ae868525774b007651c9?OpenDocument

Wow…what caused you to find this old thread and update the link? I'm sure there are hundreds of broken links that merit fixing.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Someone found this thread on a search and was looking for the correct information. Since the information was still relevant it merited correcting.

If you come across any broken links to information that is relevant please let me know and I'll address them.

Thanks Jared. I needed it today.

View this thread on the forum...