You can try saving your list of keys you want to sort and use Unix's sort
program on that savedlist. Use the port number on your saved list to make sure
it is unique.
- Original Message
From: Kevin King precisonl...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Mon,
AFAIK SSELECT BY.EXP returns a select list with the record ID and the
position in the multivalued attribute.
At least on ADDS Mentor it did.
I didn't use it for decades because I haven't had any need for such a
list, and I haven't tried it on UD yet.
So I don't think anything short of a Basic
I'll have to disagree with you on this one Tony. As a vendor yourself you
would of course think this way. As an end user of the product we would like
it all to come from one source. This is the reason that Microsoft has got
such a jump on everyone else, they will provide you with all of the tools
Let's be careful we're lobbing grenades at the right enemy. As I see things
the conflict here isn't choosing vendor supplied solutions vs. open source,
the problem is the vendor doing a poor job of making something that is
usable and truly useful.
There is a time and place for both vendor
On 10/26/2010 1:46 PM, Kevin King wrote:
But all that aside, vendors need to put more attention into their products
to make them useful and usable rather than simply another tick on a
marketing checklist.
This conversation is reminding me of a recent blog post I read.
A question for those who have done it-
I want to set up ODBC access on user PCs to Universe files for several
of my users. The Universe side is all set up.
This, of course, requires the ODBC driver be installed on the user's PC
when creating the ODBC data source.
I have this driver on my
Brilliant article! Thanks for sharing.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
We currently have it set up. But there some things you watch out for
like file names and dictionary entries with embedded periods. Email me
offline at wgbuffing...@hydro.mb.ca and I'll send you our documentation
for the setup.
-Original Message-
From:
Right Jerry!
As a VAR I have to support XDOM API. It took me hours to figure out how to
do it. Because the API was poorly documented and any examples I found made
no sense at all. When I got my code running the client could not use it
because the version of Universe did not work with XDOM
In a message dated 10/26/2010 11:58:58 AM Pacific Daylight Time,
eric.rosenzw...@petco.com writes:
In testing, it's the INPUTIF statement that's utilizing the CPU, not the
timer calculation.
Is there a better, less CPU intensive way to do this?
Thanks in advance.
INPUTIF checks
Hi Eric,
We get around this by using an optimistic locking strategy if and only
if there must be user input between the original record read and final
record write. Depending on the usage of your system, this might prove to
be a better solution?
Regards,
Dan
-Original Message-
From:
I.E., add the line with NAP in it.
You may want to try different NAP intervals to work out the best balance
between snappy user response and CPU usage.
OK = 0 ; START.DT = DATE() ; START.TM = TIME(); TIME.OUT = 900 LOOP
INPUTIF PSN
Experienced a similar thing a while back and decided to use NAP as well. Even
went as far as changing the NAP depending on how long the period of inactivity
has been.
Sample code:
LASTTIME = TIME()
FOUND.CMD = @FALSE
LOOP
UNTIL FOUND.CMD DO
ELAPSED =
I actually like the XML handling built into UV. I have always been a believer
in using the intrinsic facilities of the database where possible to maximise
the performance of the process being automated. The XDOM API is a good example
of this, and is a good fit for our requirements.
My biggest
Compared to something like lxml it seems rather clumsy and unmaintained.
On 10/26/10, Gregor Scott gregor.sc...@pentanasolutions.com wrote:
I actually like the XML handling built into UV. I have always been a
believer in using the intrinsic facilities of the database where possible to
maximise
Hi Gregor
Thanks for sharing your useful experiences and your blog.
I found the same issue with U2 MQSeries API documentation too. Although, I
guess when you are using such complex API's - it helps first to understand the
underlying technology and concepts. Be it MQSeries or XML, etc.
It was definitely 'mapped' into our world. There are steps in the API that
logically would never be used 'standalone', but as the underlying process
broke the functions out as the underlying API did -- for example -- the
PrepareXML must be followed by OpenXML -- why show that to us developers?!?
17 matches
Mail list logo
