Can anyone speak factually about internal cache in Unidata? In short...
I often look at performance and attempt to improve things by changing queries,
using indicies, rewriting source and so on. In doing so I perform timing and
consistently note that the second time a query is performed, it
Data is not the problem. Each record goes through the readnext. In this
particular instance data is exactly as the live data. In this set of
data none of the conditions are meet that would cause the continue
statement to occur. All records ran through the program write a record
in another file
What OS? How much RAM does your server have? Etc etc.
What's the likelihood that the data was on disk when you first ran the query,
and was pulled into the OS cache as a result? Second time round, the OS didn't
bother to access the disk because it was all in cache ...
Especially if your query
Can anyone speak factually about internal cache in Unidata?
I would be looking more at the operating system than UniData when it comes
to results like this. With the amount of memory available on today's
systems, it's likely that major portions (if not all) of the file(s) are
remaining in
This is a normal feature of the O/S not Unidata. Both Unix and Windows
attempt to load files into memory based on last use. Making it VERY hard to
test file access methods..!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jeffrey Butera
Sent: Monday,
quote who='Anthony Youngman' date='Monday 24 September 2007'
What OS? How much RAM does your server have? Etc etc.
What's the likelihood that the data was on disk when you first ran the
query, and was pulled into the OS cache as a result? Second time round, the
OS didn't bother to access the
At 07:33 AM 9/24/2007, you wrote:
Can anyone speak factually about internal cache in Unidata? In short...
A cache buffer is a perfectly normal operation of the OS, not the
database. This is why you are seeing the results that you are
seeing. It is often tunable in the OS on how big the
It's interesting to note that your second of three queries changes
drastically during the second invocation while the others remain the same.
Without knowing anything about your files or the dictionary items
involved, I'm going to guess that XCDD.DIV involves one or more file
translates.
Anyone able to resize the privilege file?
I'm on UniData 6.0.9 on HPUX.
I can resize all the associated SQL files, views, etc, as long as I do
so as sqlmgr (the user that created the schema).
However - if I try to resize privilege file, I consistently 'break' it.
Get the dreaded: 'No privilege
Hello,
I am new to the list, but old to PICK.
Working with Uniobjects in VB.NET to access a Unidata 7 backend database.
I am selecting records from an Accounts Payable file. The key is made up
of
VendornNumber*InvoiceNumber*SequenceNumber. Only the record with a
sequence number of 000 will
Just a hunch, but is the privilege file actually a subfile? If so, you
would have to check the permissions on both the file and the subfile.
--
Charlie Rubeor
Senior Database Administrator
Wiremold/Legrand
60 Woodlawn Street
West Hartford, CT
Hi Charles
Use the slap.lastrecordread property to check end of select rather that key
. You could run into funny issues including type mismatches that could
fall over.
Also aren't you meant to look in field 3 not field 2 of the key for 000.
If you are new to VB, it is worth considering your
David, I couldn't agree more. Use the client stuff to interface with the
user, and write the gutsy stuff in UniVerse. Almost always do I/O in
UniVerse: apart from anything else, it is so much more robust. If the
client goes down, it doesn't matter, just restart it and maybe start your
13 matches
Mail list logo
