Poorly written, implemented, designed and tested triggers - will have a
high impact on your UV system.
Hopefully, you have down a full-scale (real world-like) production-like
test in your UAT environment prior to implementing them. If you have
done this and tested real world scenarios like file,
Why not just test it?
Create a file with some number of records. Write a simple program to
select the file and change one character in the record. Write it back
to the file. Time it.
Add an AFTER UPDATE trigger calling a subroutine that does *nothing*
but a RETURN. Run the program again.
We use UniData on HP Unix, so I am not sure how much of this will transfer
over, but here are things we found:
1) Triggers must be globally cataloged. This means that if you have a
development account on that same box, you have to play games if you want to
make changes. We have both a
Brian, definitely one of my concerns was dealing with changes that were
needed in the future so I like the idea of the subtriggers. In my little
bit of testing I found that you don't want to be messing with these very
often after you set them.
Jeff, are you suggesting that I can use an index
Unless I'm off on my interpretation of VLIST's output I think the
concantenation has already taken place at compile time. If you look at line
#11 below it appears to me that a literal 'ABCD^EFGH' is being assigned to X.
I suspect that this is due to MX consisting of all literal values, no
Perry
Actually you're going to feel the pain more..
Remember that an equate is nothing more than a literal substitution by the
compiler. Every instance of MX will be replaced by 'ABCD':@AM:'EFGH'. So
everywhere you access 'MX' you will also be performing the operation
('ABCD':@AM:'EFGH').
One gotcha is that once a trigger is on there, you can't easily
change/extend it unless your system has a downtime period in which everyone
is logged out. For this reason on 24x7 sites I use a master trigger that can
call subtriggers, held as a list in a parameter file. This means that a new
Hi Perry,
Yes, you are right. The UV compiler is intelligent enough to pre-evaluate
literal concatenations at compile time.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
---
u2-users mailing list
Martin/Perry
Thanks, nice to learn it's smarter than I thought :)
Brian
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Martin Phillips
Sent: 08 October 2008 14:50
To: u2-users@listserver.u2ug.org
Subject: Re: [U2][UV] EQUATEs Using System
It's working. Thanks all! Especially David who gave me very nicely done code
that was almost ready to drop into place.
Less than an hour later and it's running, and am just tweaking some of the data.
Thanks,
Robert
David Webster [EMAIL PROTECTED] 10/7/2008 11:42 PM
Hi Robert,
I've
Brian wrote an excellent article about UniVerse Triggers in the Nov/
Dec 2007 of International Spectrum magazine (p. 12). You can download
that issue from
http://www.intl-spectrum.com/mag/NOVDEC.2007/default.aspx
Regards,
Clif
--
W. Clifton Oliver, CCP
CLIFTON OLIVER ASSOCIATES
Tel: +1
Mike:
We've been using triggers for many years; first with D3 then with UniData.
We use them mostly to keep names up-to-date and several files synchronized.
We have ten files with two triggers each on them, and these files are
reasonably small (maybe 50K records in one and less than 5K in the
To ask a naive question: Having not used Universe, are triggers and their
impact substantially different between Unidata and Universe?
I've got 47+ triggers on various Unidata (7.1.x) files, some with 50+
records and not experienced any performance issues. Like others have
commented,
We attempted to use UniData (not Universe) triggers under Windows Server
2003
and got severe file corruption. Some records in the target file were
truncated, and in
some cases segments of SB+ paragraph code were inserted into the record
at various
(inconsistent) attributes. As I said, SEVERE
Mike:
Another thing to watch out for is the transaction constraints Brian
mentioned. Where I've seen this most often is if your application has
programs that add new records to a file without first getting a record
lock with a READU. UniVerse lets you write in the dark if you want
to.
Bill,
I do this for JPEGs, TIFs, PDFs, etc, by just storing the filename in the
database. The actual BLOB file remains stored in the host O/S filesystem.
You may need to work out your own simple hierarchial directory structure to
limit the number of files per sub-directory; in my case I
If you don't get a better answer, can you save the path to the photo?
Caryl
9.1.7a way modified, dude
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brutzman, Bill
Sent: Wednesday, October 08, 2008 11:01 AM
To: u2-users@listserver.u2ug.org
Subject:
The method I've seen is to create a type 19 file with a categorized name, then
saving the files there. Then create a standard hashed file which contains a
pointer to the file by path in the first attribute.
HTH,
karl
On Wed, October 8, 2008 12:01 pm, Brutzman, Bill wrote:
Is there a way to
Check out the ENCODE() function.
Robert F. Porter, MCSE, CCNA, ZCE
Sr. Programmer / Analyst
Laboratory Information Services
Ochsner Health System
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
Yes - just base64 the binary and store that.
However it is not usually good practice to store images in a database,
usually you would store a uri/path etc to the image that can then be used,
the actual record in the data could then contain date, size , category etc
-Original Message-
Caryl:
Yes... I would rather save a path to the photo. This could be done via
wIntegrate or UniObjects.
I guess that I am set. Thanks so much.
--Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Caryl Lange
Sent: Wednesday, October 08, 2008 2:25
Bill,
Or you can use the UniVerse ENCODE() function to turn the binary
photograph data into a Base64 MV-safe form on input for storing in a
regular UniVerse file, and back into the original form for output.
And IIRC, the un-ENCODEing process arbitrarily inserts CHAR(10) every
76(?) characters.
I'd like to take issue with that, Brian. As far as I am aware what you say is
right for a LIT equate, but not for a TO equate.
With a TO equate the compiler evaluates the expression, so that the literal
string (in the current example) ABCD~EFGH would be what was substituted
throughout the
23 matches
Mail list logo
