Uniface and OCX controls
Chris Clapp
Hello there,
We are wanting to use Crystal Reports in our UNIFACE applications, using the
OCX container widget.
We are running Uniface 7.1.04, Windows NT server for our repository, data
etc, and Windows 95 clients for development.
We have installed Crystal Reports on the NT server and are now wishing to
use the OCX control. We have set up a logical widget in our ini file :
[widgets]
Crystal=uOcxContainer(ocx=g:\crw\crystl32.ocx) ; G:\ is on the NT server
It appears that the Windows Registry on the NT has been updated with the
Crystal Controls information during the Crystal Reports Installation, but
the registries on the clients have not. Is this the reason that the Crystal
Controls do not appear in the control list in the Define OCX Properties form ?
Has anyone had to manually register an OCX on their client ? If so, how did
you do it using Windows Utilities ? I am assuming that we will also need to
do this when we ship our application.
Does the OCX control have to be on the client ?
Any information would be greatly appreciated. Thanks.
+------------------------------+
| Chris Clapp |
| Inforsoft Pty Ltd |
| Hall Village Court |
| Hall ACT 2618 |
| Australia |
+------------------------------+
jeis...@wincom.net
We use WISE Installation software, available from Great Lakes
Business Solutions (www.glbs.com). Their installation software works
on Windows 3.1, Windows 95, and Windows NT platforms. The capability
to register applications is a feature of their software, as is the
ability to ship "deltas" as upgrades (for security and ability to
ship via FTP site), and to signal the client's installation of your
application by sending a message via FTP.
Try it. You'll like it!
> Date: Wed, 1 Oct 1997 17:52:18 -0700 (PDT)
> Reply-to: unif...@ctc.ctc.edu
> From: Chris Clapp <cl...@mansol.com.au>
> To: jeis...@you.wincom.net
> Subject: Uniface and OCX controls
Jack Eisenberg
jeis...@wincom.net
Chris....@bertelsmann.de
On 2nd October Chris Clapp wrote:-
(snip)
(end snip)
I don't think this has anything to do with registries.
I too couldn't get the Crystal Control to appear in the list of controls
in UDE/IDF;
but when I actually installed the Crystal Print Engine, it was OK.
(Just having the .ocx file was not enough).
Now, I had the .ocx just in the default place (c:/windows/system), but I
have just moved it to other
places (first, somewhere else on C:, and then somewhere on G:) and in
both cases the control
was visible in IDF after I changed the .ini file entry.
If you can get this to work, try pressing the "native" button in the
Widget Properties form. This should
bring up a wonderful tab dialog for setting properties. If you ever find
out what to put in here, please let
the rest of us know!
Chris Milton,
Database Solutions@Bertelsmann
> -----Original Message-----
> From: unif...@ctc.ctc.edu [SMTP:unif...@ctc.ctc.edu]
> Sent: Donnerstag, 2. Oktober 1997 13:14
> To: chris....@bertelsmann.de
> Subject: UNIFACE-L digest 794
>
> UNIFACE-L Digest 794
>
> Topics covered in this issue include:
>
> 1) Problems with 3GL
> by "Luis Fernando Mayorga Ramirez" <lmay...@softtek.com>
> 2) Re: Printing with Uniface
> by "Jan Willem Stroes" <cyp...@worldonline.nl>
> 3) RE: Problems with 3GL
> by Ilitia Rodriguez Martinez <irodr...@idisa.spin.com.mx>
> 4) Uniface 6/Oracle :USOURCE
> by Saad Ahmad <saad....@mfa.com>
> 5) RE: Problems with 3GL
> by Eduardo Robledo <erob...@idisa.spin.com.mx>
> 6) Matching Indices in Uniface and Sybase
> by VIKRAM SAINI <SAI...@GGC.COM>
> 7) Uniface and OCX controls
> by Chris Clapp <cl...@mansol.com.au>
> 8) Re: Uniface 6/Oracle :USOURCE
> by rspa...@maxwell.com
> 9) Re: Uniface and OCX controls
> by jeis...@wincom.net
> 10) RE: Matching Indices in Uniface and Sybase
> by Howard Berg <hb...@mail.on.rogers.wave.ca>
> 11) Beware of ORDER BY clause
> by Howard Berg <hb...@mail.on.rogers.wave.ca>
> 12) "SIGNOFF UNIFACE-L"
> by donat...@com.mcnet.ch (Metalor)
> 13) store -6
> by "Colin Blair" <co...@sei.co.uk>
> 14) RE: store -6
> by Mark Fairon <ma...@rubico.com>
>
> ----------------------------------------------------------------------
>
> Date: Wed, 01 Oct 1997 12:45:33 -0500
> From: "Luis Fernando Mayorga Ramirez" <lmay...@softtek.com>
> To: unif...@ctc.ctc.edu
> Subject: Problems with 3GL
> Message-ID: <34328C3D...@softtek.com>
>
> I compiled a program and, I had the following response:
>
> --------------------Configuration: async - Win32
> Debug--------------------
> Linking...
> async.obj : error LNK2001: unresolved external symbol _UPUTAMES
> async.obj : error LNK2001: unresolved external symbol _ULOADDS
> async.obj : error LNK2001: unresolved external symbol _UGETHINST
> async.obj : error LNK2001: unresolved external symbol _UMAKEPROCINST
> async___/async.dll : fatal error LNK1120: 4 unresolved externals
> Error executing link.exe.
> async.dll - 5 error(s), 0 warning(s)
>
> My library and include directories are fine
>
> Please help me
>
>
> ------------------------------
>
> Date: Tue, 30 Sep 1997 08:37:34 +0100
> From: "Jan Willem Stroes" <cyp...@worldonline.nl>
> To: <unif...@ctc.ctc.edu>
> Subject: Re: Printing with Uniface
> Message-ID: <1997100118...@triton.worldonline.nl>
>
> Cornelius Baier wrote
>
> > Hi everyone.
> > I've got a small problem trying to print with Uniface.
> > All of the fields on the print mask come out on the printer with a
> grey
> > background colour. I'm using the windows PRINTMAN device under
> Windows NT
> > 4.0, and it doesn't make any difference which printer I use.
> >
> > Any help on this would be greately appreciated.
> >
>
> Dear Cornelius,
> this is standard Uniface behaviour: all input fields are normally
> inverse.
> You can either disable the printing of inverse in the device table or
> change the properties of the form (more, default layout). The latter
> is
> probably the best solution if you use specific forms for printing.
>
> Good luck,
> Jan Willem Stroes
> j.st...@cypres.nl
>
> ------------------------------
>
> Date: Wed, 1 Oct 1997 14:07:03 -0600
> From: Ilitia Rodriguez Martinez <irodr...@idisa.spin.com.mx>
> To: "'unif...@ctc.ctc.edu'" <unif...@ctc.ctc.edu>
> Subject: RE: Problems with 3GL
> Message-ID: <01BCCE73.5B0A64E0@irodriguez>
>
> Hi.
>
> Like I told you about you Support Call 150674, this is a functionality
> =
> of Visual C++. You need set configuration in setting--> Link
> libraries =
> option.
>
> Moreover you know that is necessary:
> Add the name and path of dll in ini or ins files.
> Set U3GL variable in autoexec.bat.
> Use asynchronous interrupt with the correct proc.
>
> Anyway I will contact you by phone.
>
> Regards
> Ilitia
> Technical Support Mexico
> ----------
> De: Luis Fernando Mayorga Ramirez[SMTP:lmay...@softtek.com]
> Enviado el: Mi=E9rcoles 1 de Octubre de 1997 5:29 AM
> Para: irodr...@idisa.spin.com.mx
> Asunto: Problems with 3GL
>
> I compiled a program and, I had the following response:
>
> --------------------Configuration: async - Win32
> Debug--------------------
> Linking...
> async.obj : error LNK2001: unresolved external symbol _UPUTAMES
> async.obj : error LNK2001: unresolved external symbol _ULOADDS
> async.obj : error LNK2001: unresolved external symbol _UGETHINST
> async.obj : error LNK2001: unresolved external symbol _UMAKEPROCINST
> async___/async.dll : fatal error LNK1120: 4 unresolved externals
> Error executing link.exe.
> async.dll - 5 error(s), 0 warning(s)
>
> My library and include directories are fine
>
> Please help me
>
>
>
>
> ------------------------------
>
> Date: Wed, 01 Oct 1997 16:34:57 -0500
> From: Saad Ahmad <saad....@mfa.com>
> To: Uniface List <unif...@ctc.ctc.edu>
> Subject: Uniface 6/Oracle :USOURCE
> Message-ID: <3432C200...@mfa.com>
>
> Hello !!!
>
> Uniface 6
> Oracel 7.3.3
>
> select ulan, uvar, ucomment from usource where ulabel like
> 'U_FULLMONTHS
> %'
>
> returns:
>
> ULA UVAR UCOMMENT
> --- ----
> ----------------------------------------------------------------------
> ----------
>
> USA RF40 }
> 5JANUARY~FEBRUARY~MARCH~APRIL~MAY~JUNE~JULY~AUGUST~SEPTEMBER~OCTOBER~N
> OVEMBER~
>
> DECEMBER
>
> USA RF20 }
> 5JANUARY~FEBRUARY~MARCH~APRIL~MAY~JUNE~JULY~AUGUST~SEPTEMBER~OCTOBER~N
> OVEMBER~
>
> DECEMBER
>
> USA GUI } 4}
> 5JANUARY~FEBRUARY~MARCH~APRIL~MAY~JUNE~JULY~AUGUST~SEPTEMBER~OCTOBER~N
> OVEMB
>
> ER~DECEMBER
>
> Some questions on this ...
> 1. How is the prefix determined, ie. "} 5" or "} 4} 5" for each
> row?
> 2. Is the behavior same in version 7?
> 3. Is "~" a delimter? if so what will happen if the month name has
> "~"?
> 4. Is this delimter same in version 7?
>
>
> Thanks
> --
> -----------------------------------------
> - Saad Ahmad
> - Senior Software Engineer
> - McHugh Software International
> - e-mail saad....@mchugh.com
> - http://www.bisnet.net/~javada/saad
> -----------------------------------------
>
>
>
> ------------------------------
>
> Date: Wed, 1 Oct 1997 16:43:41 -0600
> From: Eduardo Robledo <erob...@idisa.spin.com.mx>
> To: "'unif...@ctc.ctc.edu'" <unif...@ctc.ctc.edu>
> Subject: RE: Problems with 3GL
> Message-ID: <01BCCE89.3D95CC40@erobledo>
>
>
> ------ =_NextPart_000_01BCCE89.3D9D6D60
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi,=20
>
> In this option (Setting --> Link libraries option) you need add the =
> UNIFACE libraries, this libraries are wmswlib.lib umswlib.lib yrtl.lib
> =
> and urtl.lib.
>
> Regards
>
> Ing. Eduardo Robledo
> UNIFACE Application Consultant, Mexico.
>
> ----------
> De: Ilitia Rodriguez
> Martinez[SMTP:irodr...@idisa.spin.com.mx]
> Enviado: Mi=E9rcoles 1 de Octubre de 1997 6:16 AM
> Para: erob...@idisa.spin.com.mx
> Asunto: RE: Problems with 3GL
>
> Hi.
>
> Like I told you about you Support Call 150674, this is a functionality
> =
> =3D
> of Visual C++. You need set configuration in setting--> Link
> libraries =
> =3D
> option.
>
> Moreover you know that is necessary:
> Add the name and path of dll in ini or ins files.
> Set U3GL variable in autoexec.bat.
> Use asynchronous interrupt with the correct proc.
>
> Anyway I will contact you by phone.
>
> Regards
> Ilitia
> Technical Support Mexico
> ----------
> De: Luis Fernando Mayorga Ramirez[SMTP:lmay...@softtek.com]
> Enviado el: Mi=3DE9rcoles 1 de Octubre de 1997 5:29 AM
> Para: irodr...@idisa.spin.com.mx
> Asunto: Problems with 3GL
>
> I compiled a program and, I had the following response:
>
> --------------------Configuration: async - Win32
> Debug--------------------
> Linking...
> async.obj : error LNK2001: unresolved external symbol _UPUTAMES
> async.obj : error LNK2001: unresolved external symbol _ULOADDS
> async.obj : error LNK2001: unresolved external symbol _UGETHINST
> async.obj : error LNK2001: unresolved external symbol _UMAKEPROCINST
> async___/async.dll : fatal error LNK1120: 4 unresolved externals
> Error executing link.exe.
> async.dll - 5 error(s), 0 warning(s)
>
> My library and include directories are fine
>
> Please help me
>
>
>
>
>
>
> ------ =_NextPart_000_01BCCE89.3D9D6D60
> Content-Type: application/ms-tnef
> Content-Transfer-Encoding: base64
>
> eJ8+IgkWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAg
> ABBJAG
> ACQBAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAAEkAAAAAAAAAgSsfpL6jEB
> mdbgDd
> AQ9UAgAAAAB1bmlmYWNlLWxAY3RjLmN0Yy5lZHUAU01UUAB1bmlmYWNlLWxAY3RjLmN0Yy
> 5lZHUA
> AAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAABYAAAB1bmlmYWNlLWxAY3RjLmN0Yy
> 5lZHUA
> AAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAYAAAAJ3VuaWZhY2UtbEBjdGMuY3RjLmVkdS
> cAAgEL
> MAEAAAAbAAAAU01UUDpVTklGQUNFLUxAQ1RDLkNUQy5FRFUAAAMAADkAAAAACwBAOgEAAA
> ACAfYP
> AQAAAAQAAAAAAAADmDQBCIAHABgAAABJUE0uTWljcm9zb2Z0IE1haWwuTm90ZQAxCAEEgA
> EAFgAA
> AFJFOiBQcm9ibGVtcyB3aXRoIDNHTAD3BgEFgAMADgAAAM0HCgABABAAKwApAAMARgEBII
> ADAA4A
> AADNBwoAAQAQACgAGwADADUBAQmAAQAhAAAARTgwNDk4QkQ3QjNBRDExMThGMkM0NDQ1NT
> M1NDAw
> MDAA8QYBA5AGAKQGAAASAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwA2AAAAAABAAD
> kAwJn/
> drvOvAEeAHAAAQAAABYAAABSRTogUHJvYmxlbXMgd2l0aCAzR0wAAAACAXEAAQAAABYAAA
> ABvM67
> dva9mATpOnsR0Y8sREVTVAAAAAAeAB4MAQAAAAMAAABNUwAAHgAfDAEAAAAbAAAAV09SS0
> dST1VQ
> L1BBTkRPUkEvRVJPQkxFRE8AAAMABhBd3Ya0AwAHEC8FAAAeAAgQAQAAAGUAAABISSxJTl
> RISVNP
> UFRJT04oU0VUVElORy0tTElOS0xJQlJBUklFU09QVElPTilZT1VORUVEQUREVEhFVU5JRk
> FDRUxJ
> QlJBUklFUyxUSElTTElCUkFSSUVTQVJFV01TV0xJQkxJAAAAAAIBCRABAAAAJwUAACMFAA
> D7CQAA
> TFpGddzKTAb/AAoBDwIVAqgF6wKDAFAC8gkCAGNoCsBzZXQyNwYABsMCgzIDxQIAcHJCcR
> Hic3Rl
> bQKDM3cC5AcTAoB9CoAIzwnZO/EWDzI1NQKACoENsQtg4G5nMTAzFFALChRRBQvyYwBAIE
> hpLCBL
> CoUKhUkDoHRoBAAgym8FMGkCICAoBmACQAELgGcgLS0+IEyBC4BrIGxpYnIKwCMIkBx2KS
> B5CGAg
> bmEJ4GQgYWQfsBxAZQAgVU5JRkFDRT8eGBsQHEMeKArAIDB3bUsD4B4hLh4hIHUiyXl9AC
> BsIyMA
> cB+wCHAkVC5RGzxSZWcLEXMbPmegLiBFZHULEW8H8ZsCYAmAbwqFIFZBcAtQOGljYRyzCF
> AAgHVs
> RwGQAjAbEE1leCowb0cljQr0HiAxODAC0WnwLTE0NA3wDNAtwwtZ3DE2CqADYBPQYwVAHZ
> AfL+YK
> hy6bDDAvZkRlOv4gMrIufy+EDIIcAB4gHLCqYQfxZAUQZwpQegXQBwrAHUE1oFtTTVRQjD
> ppA2A1
> VUBpZAQAUGEuc3ALgC4FoG0wLm14XTCPMZ1Fbr52BzAoYDKgMw80GU0AoPAnZTlyFYEHkR
> rQDbB0
> IE8vsHUeQCAwPcExwDk5NyA2Oi8wFLDWTTiPMZ1QCsBhMqI7H280GQSQKKQ3X3g/bzGdQZ
> 8q4AIw
> OuEyzzPdUkVHoB5QQ7MiwCKgNOBoIDPMR0wr7yzzMzYuZxpFry9mGvAljR3QayAwSRwwfw
> bwH7Af
> QgGgCGAFQB9CUz51KgAVsSqgB0ADIDE1cDA2NzQhZRxhNRBmH0dgL7AcwQdANOB5ID3hCo
> VvZiBW
> BAAoMAMgyEMrKyfwIFkfVhGx+iAFoG4tkDWAHlAcswuAf1WSHUIdnwQgU5ccoyWNTTEFsG
> VvdgSQ
> HzNrbr5vB+AcQCpQUlIfgGMHkNE3kHJ5OgqFQR/lUyDfB4AkswqwSrFUEWRRYVbB/QuAaR
> yABcAL
> gAQgLZA9YZ8lhjRzHREgQErhIHYeYdcBoCjAVrJhUFBvK4AFkGwuYipQYBtVEbAfwHPaeV
> LQaANg
> W0B1UkECMP0EkHJQ0AVASpMgEgWhFhAPL7EvYWKgGzxBbnl3/mFTcE9wA/BRYVXhAZAvsa
> UfQmJT
> cHBoAiBlJY/XJpo0xAqFVAWQaAMAKkA/AyBQxit0CoUv7zKDTHV9HGFGBJEkwShwNdAfQH
> LfJpAH
> 8F2gNrA2NmwAwHDDzEBzVBACQGVrOAI4dps6hUOQbEehPNA9RT0v4T46NToyOT84QWU2v9
> 9En0c4
> Sg8bPVXRbTfQKMH/UoEvYQnAXaAkshsQT3ARgP8f9AIQUWBbUB1SFhA3wCrB/zKQGzxuaG
> 5oKrFW
> GEegZANJHYAgVwuAMzJvB2K+dVdRhL8wdh3SHVEuhsDLCoVkAy4ooGogR6BlAZEFsUxOSw
> HQMDFH
> oP9HYH9xBvBasB+wK4Bk8VMhA1WQBsMgX1VQVVR5P0BFU4b/iA+JH4oqTPBPQUREi0+MX4
> 1vihsA
> R0VUSElOU1QPj6+Qv5HPiipNQUtFUFBST0OT3l+ZgC93lIReokegZipQVIGVRzF2MQHQR6
> A0li9T
> ISbWRb+VU2JyUFAdUh4gHfAuYnEXhuxeooNwNZU0KHMp/RsQMCKgCsADABkQoNFZjd9TcB
> 4kU3Ak
> wguAYwpAdWF/N3BmMgWwIjYtkB+AGzxQjyjAZAAgMCAgbHAgB4B/Gzynr0tPTF9NaQqFFT
> EAAayg
> AAMAEBAAAAAAAwAREAAAAABAAAcwgPvsA7vOvAFAAAgwgPvsA7vOvAEeAD0AAQAAAAUAAA
> BSRTog
> AAAAANoD
>
> ------ =_NextPart_000_01BCCE89.3D9D6D60--
>
>
> ------------------------------
>
> Date: Wed, 01 Oct 1997 17:30:05 -0500
> From: VIKRAM SAINI <SAI...@GGC.COM>
> To: unif...@ctc.ctc.edu
> Subject: Matching Indices in Uniface and Sybase
> Message-ID: <s43287...@GGC.COM>
>
> Hi,
>
> We are using Uniface 6.1.dl with Sybase 11.
> We have a situation where in one of the Sybase tables Indices are
> defined as
> I1 - CLUSTERED, fields 1,2,3,4,5,6
> I2 - NONCLUSTERED, field 3,1,2
> I3 - NONCLUSTERED, field 7
> I4 - NONCLUSTERED, field 8
>
> Group of fields on which index I1 is defined is not unique. In
> Uniface, we
> have to define a primary key and knowing that a primary key is always
> the first key in the entity (correct me if I am wrong) we defined a
> primary
> key on the field A. Obviously, field A is unique. But our Sybase DBA
> doesn't want to define a clustered unique index (as created by Uniface
> in the script on Create Table utility) just for field A, especially
> when field
> A is not even used in the retrieval/search etc. In other words field A
> is
> insiginificant, it's just a sequential number.
> In Sybase we can define only one clustered index and we don't
> necessarily need to define an index for the primary key in Uniface,
> right?
> But now in Uniface my keys refer to wrong indices in Sybase.
> 1 - -Primary key on field A
> 2 --Index, fields 1,2,3,4,5,6
> 3 - -Index, field 3,1,2
> 4 - -Index, field 7
> 5 - -Index, field 8
>
> Only solution that I think of right now is to redefine the indices in
> Sybase
> by incrementing them by one so they will match Uniface index keys
> sequence. Finally, we will have I2, I3, I4, I5 and NO I1.
>
> Let me know if you could think of a better solution to resolve this
> problem? Thanks.
>
> -Vikram
>
> ps: Will it be ok to define a nonclustered index on a primary key
> (field A),
> if we really have to define an index I1 on field A (primary key) in
> Sybase?
>
>
> ------------------------------
>
> Date: Thu, 2 Oct 1997 12:44:09 +1000
> From: Chris Clapp <cl...@mansol.com.au>
> To: unif...@ctc.ctc.edu
> Subject: Uniface and OCX controls
> Message-ID: <1997100202...@rincewind.mansol.com.au>
> ------------------------------
>
> Date: Wed, 1 Oct 1997 17:53:53 -0700
> From: rspa...@maxwell.com
> To: unif...@ctc.ctc.edu
> Subject: Re: Uniface 6/Oracle :USOURCE
> Message-ID: <88256524.0...@otis.maxwell.com>
>
>
> What you're looking at is the raw stored data.
> What you want is what Uniface interprets.
> You should create a fast-form for USOURCE or UFORM/U?GROUP/U?FIELD and
> view
> the data that way.
> You'll find that the internal uniface delimiters ({, |, }, ~) no
> longer
> show up, nor do the mysterious numbers that probably represent record
> numbers.
>
> To answer your 3rd question, raw values that would otherwise become
> internal delimiters are translated into other codes. For example, "{"
> would become "{A" (or something like that).
>
>
>
>
>
> saad....@mfa.com on 10/01/97 02:38:52 PM
>
> Please respond to unif...@ctc.ctc.edu
>
> To: Rob Spahitz/BusSys/ISD/Maxwell
> cc:
> Subject: Uniface 6/Oracle :USOURCE
>
>
>
>
> Hello !!!
> Uniface 6
> Oracel 7.3.3
> select ulan, uvar, ucomment from usource where ulabel like
> 'U_FULLMONTHS
> %'
> returns:
> ULA UVAR UCOMMENT
> --- ----
> ----------------------------------------------------------------------
> -----
> -----
> USA RF40 }
> 5JANUARY~FEBRUARY~MARCH~APRIL~MAY~JUNE~JULY~AUGUST~SEPTEMBER~OCTOBER~N
> OVEMB
> ER~
> DECEMBER
> USA RF20 }
> 5JANUARY~FEBRUARY~MARCH~APRIL~MAY~JUNE~JULY~AUGUST~SEPTEMBER~OCTOBER~N
> OVEMB
> ER~
> DECEMBER
> USA GUI } 4}
> 5JANUARY~FEBRUARY~MARCH~APRIL~MAY~JUNE~JULY~AUGUST~SEPTEMBER~OCTOBER~N
> OVEMB
> ER~DECEMBER
> Some questions on this ...
> 1. How is the prefix determined, ie. "} 5" or "} 4} 5" for each
> row?
> 2. Is the behavior same in version 7?
> 3. Is "~" a delimter? if so what will happen if the month name has
> "~"?
> 4. Is this delimter same in version 7?
>
> Thanks
> --
> -----------------------------------------
> - Saad Ahmad
> - Senior Software Engineer
> - McHugh Software International
> - e-mail saad....@mchugh.com
> - http://www.bisnet.net/~javada/saad
> -----------------------------------------
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Date: Wed, 1 Oct 1997 22:23:32 +0000
> From: jeis...@wincom.net
> To: unif...@ctc.ctc.edu
> Subject: Re: Uniface and OCX controls
> Message-ID: <1997100202...@mail.wincom.net>
> ------------------------------
>
> Date: Wed, 1 Oct 1997 19:57:03 -0400
> From: Howard Berg <hb...@mail.on.rogers.wave.ca>
> To: "'unif...@ctc.ctc.edu'" <unif...@ctc.ctc.edu>
> Subject: RE: Matching Indices in Uniface and Sybase
> Message-ID: <01BCCEBA.D1FE15A0@bergium>
>
> <<In Sybase we can define only one clustered index and we don't
> necessarily need to define an index for the primary key in Uniface,
> right?>>
> >>Wrong. You must have a unique index for the primary key defined in
> Uniface. It is used for locking, and CRUD access. As long as you
> recreate the primary key as a unique index (not necessarily
> clustered), you may drop any index and recreate it as your DBA would
> like to do. Normal CRUD access will not be affected.
>
> <<Will it be ok to define a non-clustered index on a primary key
> (field A),
> if we really have to define an index I1 on field A (primary key) in
> Sybase?>>
> >>Yes you must. This is the way to do it. For the least amount of
> work, order the indexes so that the index you want to be clustered is
> 2nd on the list. Then you merely drop the first two indexes and
> recreate them in SYBASE.
>
> Note however that there are stored procedures also created by Uniface
> which Uniface uses to manage the hitlist for sorting and sequenced
> retrievals. These procedures are named <tablename>_S1,
> <tablename>_SN1, <tablename>_S2, <tablename>_SN2 etc. Here
> <tablename>_S1 refers to Sequence 1, SN1 refers to SequenceNext 1. For
> example, if Uniface was retrieving a list of records with an "ORDER
> BY" clause in the <read> trigger that matched one of the Uniface Keys
> (say the second), then it would use the procedure <tablename>_S2 to
> seek the first and <tablename>_SN2 to seek the next. If you mix up the
> order of the keys in SYBASE, you must either drop the stored
> procedures for these seeks or recreate them to match the new pattern.
> This is not difficult to do, it just takes a little patience with a
> text editor and the table-create script. It does become a pain if the
> table is changing but it is fine for a stable production environment.
> Ask your DBA to let it ride for the period which the !
> table structure is volatile.
>
> Also note that there is a construct in Uniface that permits you to use
> a numeric argument in the <read> trigger.
> For example read using 1. I do not understand the underlying operation
> of this syntax and I would not recommend it especially if you are
> rearranging the indexes. Stick to the literal construct: read order by
> "FIELDA".
>
> By the way, use at least version 6.1dp -- it fixed some nasty
> formatting problems with the u_where clause.
>
> I hope this helps,
>
> Howard Berg
> Kitchener, Ontario, Canada.
>
> -----Original Message-----
> From: VIKRAM SAINI [SMTP:SAI...@GGC.COM]
> Sent: Wednesday, October 01, 1997 6:31 PM
> To: hb...@rogers.wave.ca
> Subject: Matching Indices in Uniface and Sybase
>
> Hi,
>
> We are using Uniface 6.1.dl with Sybase 11.
> We have a situation where in one of the Sybase tables Indices are
> defined as
> I1 - CLUSTERED, fields 1,2,3,4,5,6
> I2 - NONCLUSTERED, field 3,1,2
> I3 - NONCLUSTERED, field 7
> I4 - NONCLUSTERED, field 8
>
> Group of fields on which index I1 is defined is not unique. In
> Uniface, we
> have to define a primary key and knowing that a primary key is always
> the first key in the entity (correct me if I am wrong) we defined a
> primary
> key on the field A. Obviously, field A is unique. But our Sybase DBA
> doesn't want to define a clustered unique index (as created by Uniface
> in the script on Create Table utility) just for field A, especially
> when field
> A is not even used in the retrieval/search etc. In other words field A
> is
> insiginificant, it's just a sequential number.
> In Sybase we can define only one clustered index and we don't
> necessarily need to define an index for the primary key in Uniface,
> right?
> But now in Uniface my keys refer to wrong indices in Sybase.
> 1 - -Primary key on field A
> 2 --Index, fields 1,2,3,4,5,6
> 3 - -Index, field 3,1,2
> 4 - -Index, field 7
> 5 - -Index, field 8
>
> Only solution that I think of right now is to redefine the indices in
> Sybase
> by incrementing them by one so they will match Uniface index keys
> sequence. Finally, we will have I2, I3, I4, I5 and NO I1.
>
> Let me know if you could think of a better solution to resolve this
> problem? Thanks.
>
> -Vikram
>
> ps: Will it be ok to define a nonclustered index on a primary key
> (field A),
> if we really have to define an index I1 on field A (primary key) in
> Sybase?
>
>
>
> ------------------------------
>
> Date: Wed, 1 Oct 1997 20:11:03 -0400
> From: Howard Berg <hb...@mail.on.rogers.wave.ca>
> To: "'unif...@ctc.ctc.edu'" <unif...@ctc.ctc.edu>
> Subject: Beware of ORDER BY clause
> Message-ID: <01BCCEBA.D4816520@bergium>
>
>
> ------ =_NextPart_000_01BCCEBA.D482EBC0
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> I want to warn other developers about a Uniface bug that crashes the =
> application with an infinite loop. This rarely gets out of the shop =
> because it either hangs the machine or gives you a GPF. Until
> Compuware =
> fixes it (I am using 6.1dp) here is a warning that will help you =
> diagnose bizarre crashes.
>
> I often get into the SQL syntax habit of typing=20
> select...where...order by FIELDA
>
> I then type this into Uniface as=20
> read u_where...order by FIELDA=20
> (forgetting the "double quotes" around "FIELDA").=20
>
> In this situation Uniface gets caught in an infinite loop because
> during =
> the retrieve, it fires the <read> trigger to get the first record but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but
>
> in order to use the value of FIELDA to substitute as a string to use
> for =
> the order by clause it must fire the <read> trigger to read the value
> of =
> FIELDA but...
>
> I hope this helps,
>
> Howard Berg
> Kitchener, Ontario, Canada.
> ------ =_NextPart_000_01BCCEBA.D482EBC0
> Content-Type: application/ms-tnef
> Content-Transfer-Encoding: base64
>
> eJ8+IggCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS
> 5NaWNy
> b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAsAEAAAEAAAAQAAAAAwAAMA
> IAAAAL
> AA8OAAAAAAIB/w8BAAAASQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVuaWZhY2UtbE
> BjdGMu
> Y3RjLmVkdQBTTVRQAHVuaWZhY2UtbEBjdGMuY3RjLmVkdQAAAAAeAAIwAQAAAAUAAABTTV
> RQAAAA
> AB4AAzABAAAAFgAAAHVuaWZhY2UtbEBjdGMuY3RjLmVkdQAAAAMAFQwBAAAAAwD+DwYAAA
> AeAAEw
> AQAAABgAAAAndW5pZmFjZS1sQGN0Yy5jdGMuZWR1JwACAQswAQAAABsAAABTTVRQOlVOSU
> ZBQ0Ut
> TEBDVEMuQ1RDLkVEVQAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAAFgAAAHVuaWZhY2UtbE
> BjdGMu
> Y3RjLmVkdQAAAAIB918BAAAASQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVuaWZhY2
> UtbEBj
> dGMuY3RjLmVkdQBTTVRQAHVuaWZhY2UtbEBjdGMuY3RjLmVkdQAAAAADAP1fAQAAAAMA/1
> 8AAAAA
> AgH2DwEAAAAEAAAAAAAAAllYAQSAAQAaAAAAQmV3YXJlIG9mIE9SREVSIEJZIGNsYXVzZQ
> A/CAEF
> gAMADgAAAM0HCgABABQACwADAAMABAEBIIADAA4AAADNBwoAAQATADkAEgADAEABAQmAAQ
> AhAAAA
> NTZBMEUyNTlBRjNBRDExMTg0REIwMDAwQzBBQ0NCRTkAPwcBA5AGALAHAAAiAAAACwACAA
> EAAAAL
> ACMAAQAAAAMAJgAAAAAACwApAAEAAAADAC4AAAAAAAIBMQABAAAAyQAAAFBDREZFQjA5AA
> EAAgBK
> AAAAAAAAADihuxAF5RAaobsIACsqVsIAAE1TUFNULkRMTAAAAAAATklUQfm/uAEAqgA32W
> 4AAABZ
> OlxXSU5OVFxtYWlsYm94LnBzdAAYAAAAAAAAABxw1JS+dtARp6YAQAUUDzeigAAAAAAAAB
> gAAAAA
> AAAAHHDUlL520BGnpgBABRQPN8KAAAAQAAAAVqDiWa860RGE2wAAwKzL6RoAAABCZXdhcm
> Ugb2Yg
> T1JERVIgQlkgY2xhdXNlAAAAAAMANgAAAAAAQAA5AACu7KvHzrwBHgBwAAEAAAAaAAAAQm
> V3YXJl
> IG9mIE9SREVSIEJZIGNsYXVzZQAAAAIBcQABAAAAFgAAAAG8zser5lnioFg6rxHRhNsAAM
> Csy+kA
> AB4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAVAAAAaGJlcmdAcm9nZXJzLndhdmUuY2
> EAAAAA
> AwAGEGwhZ5QDAAcQhAYAAB4ACBABAAAAZQAAAElXQU5UVE9XQVJOT1RIRVJERVZFTE9QRV
> JTQUJP
> VVRBVU5JRkFDRUJVR1RIQVRDUkFTSEVTVEhFQVBQTElDQVRJT05XSVRIQU5JTkZJTklURU
> xPT1BU
> SElTUkFSRUxZR0VUU08AAAAAAgEJEAEAAAC7AwAAtwMAAMIJAABMWkZ19heKNvcACgEDAf
> cgAqQD
> 5AcTAoMnAFAC8gIAY2gKwHNlwHQwIFRhaANxAoNuMgPFEGkPZX0KgAjIIGI7CW8yNTUCgA
> qBdTZj
> AFALA2MAQQtgbmcQMTAzMwumIEkgZncAcAVAdG8X0QShb5R0aASQIAEAdmUJAD5wBJAEIA
> GgCGAF
> QGEgClUDAGYA0GUgYnWeZxggEJAFQAUAYXMY0JcEIBjBGbBwC1BpYxsg9mkCIBfQaRjAGb
> ADoAuA
> vmYLgBzgGqAJABlgLhEAGmgEACAbYAlwbHkgzmcQ0AQgGeJvZhvDG4DnGWAasAWQYXUQwB
> 1ABUD+
> ZRzhGOEQkBbQG7QAwR5QZm4aoAWxZ2kZMAQgeeMIYBoRR1BGHiAaQByA4wMgCFBtcHUYYR
> qgHXAW
> eAeRINEoF8BhbSAHIJALgBrgNi4xZHD+KSFgBJAgsRmhGFMl4hsDbQPwbAMgGNBsIDAjIm
> QRBzBn
> bm8goWJpevcKwCShG1UuCqIKhAqAF8B/H5AdsAOgHwEdQRgxG9JTlFFMH/B5AjBheCFhcy
> lwH3R5
> cCXiKnQQwGzpBZB0Li7wdyaSLvEFsAcEgRqwHuBGSUVMRP5BKnwYwQOgLcEaoBjAHmGfK/
> MaRhtw
> LiUJcGFkJbCuXy8vMDQuJSgCEHIfAeccgCeDGqAiZAhgAmAaoGxxdRiwB5AiGbADYHXKbj
> PwIjA0
> IikeICp75zGhHlIAkHR1HHQaRh8DuSBxZ2gr0h0fIEdkCHHbNqUJcHQIgRkwLCDCHXBrCX
> AbtDwz
> wj4YIAUQZ78fAAXAGDErshvSP5FzBUDvCXAFoTPwGsB0Kno8US+k9xgxIJIb0nYHQApQH4
> I1Rf0Y
> MXM3QEIAOoEdsTMxGiC/QgA+NEQ0NiEbwy+nYwtg/SCVbSCQP3Q/70D0M8NEn/81gUKvQ7
> 9MH0Xf
> Ru9H/0kP/0ofSy9MP01PTl9Pb1B/UY//Up9Tr1S/Vc9W31fvWP9aD/9bH1wvXT9eT19fYG
> 9hf2KP
> /2OfZK9lv2bPZ99o72n/aw//bB9tL24/b09wX3Fvcn9zj/90n3Wvdr93z3jfee96/3wP/3
> 0ffi9/
> P4BPgV+Cb4N/hI//hZ+Gr4e/iM+J344fi/+ND/+Vb48vkD+RT5Jfk2+Uf5i/P5aSLvEqeh
> ZhAtEQ
> AXMxnjcXsSARMfUoUnMsKnqsSG8YYTPwQgSQZyp0vksc4BCACfAEkD9ATyzhtQUQbz9AQw
> BwM+Bh
> KmBfFnIRswwBKoMTYQCpEAADABAQAAAAAAMAERABAAAAAwCAEP////9AAAcw0BnWv8XOvA
> FAAAgw
> 0BnWv8XOvAELAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAM
> AAAAAA
> AABGAAAAABCFAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcNAAAeACaACC
> AGAAAA
> AADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAngAggBgAAAAAAwAAAAAAAAEYAAA
> AAAYUA
> AAAAAAALADCACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMYAIIAYAAAAAAMAAAA
> AAAABG
> AAAAABGFAAAAAAAAAwAzgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEKACCAGAA
> AAAADA
> AAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBDgAggBgAAAAAAwAAAAAAAAEYAAAAAN4
> UAAAEA
> AAABAAAAAAAAAB4ARIAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD
> 0AAQAA
> AAEAAAAAAAAAAwANNP03AAA1/g==
>
> ------ =_NextPart_000_01BCCEBA.D482EBC0--
>
>
> ------------------------------
>
> Date: Thu, 2 Oct 1997 08:53:21 +0100
> From: donat...@com.mcnet.ch (Metalor)
> To: unif...@ctc.ctc.edu
> Subject: "SIGNOFF UNIFACE-L"
> Message-ID: <19971002084...@ne1-a1.mcnet.ch>
>
> "SIGNOFF UNIFACE-L"
>
> ------------------------------
>
> Date: Thu, 2 Oct 1997 09:51:56 +0100
> From: "Colin Blair" <co...@sei.co.uk>
> To: "Uniface" <unif...@ctc.edu>
> Subject: store -6
> Message-ID: <1997100209...@sei4.sei>
>
> Uniface 6.1.dp - Informix 7.12
>
> We occasionally get a -6 error when we attempt a store, but if you
> clear
> and re-input data, the store is successful. The manual gives us the
> "Exceptional i/o error" stuff but not much else and we are having
> difficulty tracking down the source of these errors.
>
> Does anyone have any ideas or suggestions? We would be most pleased.
>
> colin blair - soi
> (co...@sei.co.uk)
>
>
> ------------------------------
>
> Date: Thu, 2 Oct 1997 12:24:01 +0200
> From: Mark Fairon <ma...@rubico.com>
> To: "'unif...@ctc.ctc.edu'" <unif...@ctc.ctc.edu>
> Subject: RE: store -6
> Message-ID: <01BCCF2E...@nin.rubico.com>
>
>
> ------ =_NextPart_000_01BCCF2E.127F2920
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> If you get a -6, something is wrong with your database. Look in the =
> message FRAME. There should be error(s) in there. They tend to be =
> technically accurate.
>
> POP
>
> -----Original Message-----
> From: Colin Blair [SMTP:co...@sei.co.uk]
> Sent: Thursday, October 02, 1997 12:07 PM
> To: ma...@rubico.com
> Subject: store -6
>
> Uniface 6.1.dp - Informix 7.12
>
> We occasionally get a -6 error when we attempt a store, but if you
> clear
> and re-input data, the store is successful. The manual gives us the
> "Exceptional i/o error" stuff but not much else and we are having
> difficulty tracking down the source of these errors.
>
> Does anyone have any ideas or suggestions? We would be most pleased.
>
> colin blair - soi
> (co...@sei.co.uk)
>
>
> ------ =_NextPart_000_01BCCF2E.127F2920
> Content-Type: application/ms-tnef
> Content-Transfer-Encoding: base64
>
> eJ8+IgQKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS
> 5NaWNy
> b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAsAEAAAEAAAAQAAAAAwAAMA
> IAAAAL
> AA8OAAAAAAIB/w8BAAAASQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVuaWZhY2UtbE
> BjdGMu
> Y3RjLmVkdQBTTVRQAHVuaWZhY2UtbEBjdGMuY3RjLmVkdQAAAAAeAAIwAQAAAAUAAABTTV
> RQAAAA
> AB4AAzABAAAAFgAAAHVuaWZhY2UtbEBjdGMuY3RjLmVkdQAAAAMAFQwBAAAAAwD+DwYAAA
> AeAAEw
> AQAAABgAAAAndW5pZmFjZS1sQGN0Yy5jdGMuZWR1JwACAQswAQAAABsAAABTTVRQOlVOSU
> ZBQ0Ut
> TEBDVEMuQ1RDLkVEVQAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAAFgAAAHVuaWZhY2UtbE
> BjdGMu
> Y3RjLmVkdQAAAAIB918BAAAASQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVuaWZhY2
> UtbEBj
> dGMuY3RjLmVkdQBTTVRQAHVuaWZhY2UtbEBjdGMuY3RjLmVkdQAAAAADAP1fAQAAAAMA/1
> 8AAAAA
> AgH2DwEAAAAEAAAAAAAAAllYAQSAAQANAAAAUkU6IHN0b3JlIC02AKEDAQWAAwAOAAAAzQ
> cKAAIA
> DAAYAAEABAAJAQEggAMADgAAAM0HCgACAAwAFgAqAAQAMAEBCYABACEAAABFNjNGNjY0RE
> Y1M0FE
> MTExOTc5NDAwQTAyNDY1M0I1NgD9BgEDkAYAOAYAACEAAAALAAIAAQAAAAsAIwAAAAAAAw
> AmAAAA
> AAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAoPYHTR3PvAEeAHAAAQAAAA0AAABSRT
> ogc3Rv
> cmUgLTYAAAAAAgFxAAEAAAAWAAAAAbzPHUxpTWY/5zr1EdGXlACgJGU7VgAAHgAeDAEAAA
> AFAAAA
> U01UUAAAAAAeAB8MAQAAABAAAABtYXJrQHJ1Ymljby5jb20AAwAGECTJCIADAAcQOwIAAB
> 4ACBAB
> AAAAZQAAAElGWU9VR0VUQS02LFNPTUVUSElOR0lTV1JPTkdXSVRIWU9VUkRBVEFCQVNFTE
> 9PS0lO
> VEhFTUVTU0FHRUZSQU1FVEhFUkVTSE9VTERCRUVSUk9SKFMpSU5USEVSRVRIRVlURU4AAA
> AAAgEJ
> EAEAAAAqAwAAJgMAAGYEAABMWkZ1WsRCHXcACgEDAfcgAqQE9AIAY4JoCsBzZXQwIAhQ+G
> 1pYwYE
> BeACgwBQA9TBAgBwcnEyIAcTAoAmfQqACMggOwlvMjVmNQKACoF1YwBQCwNjAwBBC2BuZz
> EwMzNB
> C6YgSWYgeQhgIAJnD9AgYSAtNiwsIHMDcA/QaAuAZyD5BAAgdwNgGHED8BhAFxIpBcBkYQ
> GRYQ/A
> LiBwTG9vaxiQA6AYQGUSIAeBc2EXYCBGUuhBTUUaUFQbAAlwF/DCaAhgbGQgYhsQBJDhA2
> ByKHMp
> GrUJcBwDznka4AnwHNB0bxziHqBrD4ADAGMHQGwegADQYz8IcBngGkAKogqECoBQT95QIK
> oVkQFA
> EdBvH1EPUVkRMjE2F7Ajok8FEGf/C4AHQAXQG0QjoyCmIrQigYMLEyK2aS0xNDQBQNxsaS
> dDDNAn
> Q2IboANhujoMg2IP8ieQA6BCC2GBBcBbU01UUDoI4SULgEAPwGkuBaAudfxrXSClKHAGYA
> IwKNcc
> IFUIcHMZ0HkX4E8i8G8THPAFwDAyF+AxOTkiNy4wMjowLnBQTRkrh1RvKNcAwHJrQLhydW
> IQQCsw
> BaBtK4jtMLBqIuEo13Me8BxRF8CvJU8mWwvFILNVAwBmANCBGxA2LjEuZHAXsBUW4G4CEH
> IQMHgg
> N9U2gDIgqlcbEG8gIBog/mkCIB/DF2YdFBjAGwADoO53GxAZ4B6gbQUxF6Ay0zkX4GJ1BU
> AGkBcT
> Y2y+ZQrAIKQAcBzQCXAtC4B+cDwhGdIX4BryMtQYoXN3FRA2QAQQZhywHAMwQW7WdSRRJC
> B2B5F1
> BCAa8fEgpCJFeDZABTA5ExiQ1i8fAB0jIjLBdQEgPAOebiLAGyAVEBlgZWwPwN8XkB7BOt
> IcUQ+Q
> dhhhIKTOZAaQJxAgMGx0HoEgUMRjaxhiZG93GtQYAHsIcDZBbxcAGvFE0R0jc7kgm0RvB5
> EAcBcg
> bkWT+0TiHoBpAQAaIDiwBcA/cI5nF2Ay0DkRcz8gOJHudxymBGAy0CALUEvhCYD/IJsqgx
> zgKdM2
> 4BgAAKAgs7ooKo0pIZsgsxKRAFNQAAADABAQAAAAAAMAERAAAAAAAwCAEP////9AAAcwYJ
> L0HR3P
> vAFAAAgwYJL0HR3PvAEDAAGACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABIAIIA
> YAAAAA
> AMAAAAAAAABGAAAAAFKFAAC3DQAAHgAFgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAA
> AEAAAA
> OC4wAAMABoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwALgAggBgAAAAAAwAAAAA
> AAAEYA
> AAAAA4UAAAAAAAALABCACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAEYAIIAYAAA
> AAAMAA
> AAAAAABGAAAAABGFAAAAAAAAAwAUgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAC
> SACCAG
> AAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAlgAggBgAAAAAAwAAAAAAAAE
> YAAAAA
> N4UAAAEAAAABAAAAAAAAAB4AJoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAA
> AAAAAe
> AD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAAlGg=
>
> ------ =_NextPart_000_01BCCF2E.127F2920--
>
>
> ------------------------------
>
> End of UNIFACE-L Digest 794
> ***************************