Gregor Scott
System Group Manager
I have been working with UV for a few years now but I occasionally uncover some
functionality I never knew existed that is really cool and useful.
Such as the invisible @TMP table (I just crated this post about it:
http://wp.me/p1692U-1o).
It is documented in th
ALLOWMARKS in uvconfig??
JayJay
> On 26 Nov 2013, at 16:15, Chris Austin wrote:
>
> Hello,
>
> I noticed an error when doing a UVRESTORE. We have a UniVerse region with
> client information and data. When doing a UVRESTORE I get the following >
>
> Restoring c:\CHRIS/I_CLIENT (21:35:56)
>
I figured it out. It wasn't one of the @ID's.. rather an I-descriptor that we
had indexed on that CLIENT table that was calculating
EXACTLY how that message displays.
For example, the symbolic (I-Descriptor) for one of the records is calculating
>
"Z29864873 ýA38385000 "
I app
I had this error once. This happens when the @tm, @sm @vm exists in the
indexed field (or if the indexed field is > than the maximum key size (as
defined in the CONFIG MAXKEYSIZE command) So you may have to write a program
to analyse the result of your I-descriptor field used for indexing.
I wrote a program to check for @VM, @SVM, and @FM on every record in that table
and it didn't find anything so
it must be something else.
The part I'm struggling with is locating what this means >
Unable to write item "Z29864873 ýA38385000 ".
since there's no ý in the @IDs. I
If I recall, the checksum itself is account specific. So if the checksum
were being calculated for one account but accessing sb resources/processes
from another, could that be triggering the checksum mismatch?
On Tuesday, November 26, 2013, Israel, John R. wrote:
> Kevin,
>
> This is a temporary
Thanks Bob,
I like the idea of using an I-descriptor to DCOUNT on the @ID :)
Cheers
Chris
> Date: Tue, 26 Nov 2013 13:58:22 -0800
> From: bob_woodw...@k2sports.com
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] UvRestore error
>
> One of the ways that I've used in the past to check fo
One of the ways that I've used in the past to check for @VM's, @SVM's, and
@TM's is to do a simple SELECT of the file, a SAVE.LIST, then EDIT.LIST. A
simple scan usually shows the errant record ID's because they are usually
longer than the rest of the record ID's making them stick out like a so
The examples I posted below appear to be when it builds the INDEX on the table
CLIENT. I'm just not sure if it's referring
to the actual ID of the record.. or a field inside that CLIENT record?
> Date: Tue, 26 Nov 2013 13:44:34 -0800
> From: jhes...@momtex.com
> To: u2-users@listserver.u2ug.o
There appear to be some in the examples you posted. They appear as "ý" in a
lot of terminal emulations. You can verify how they appear on your screen by
editing one into a record:
ED BP MV.TEST
I ^253
-John
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-use
John, Thanks for the reply.
I'll write a utility to parse the ID's on that table and see if I find any
@VM's.. I did notice some unconventional ID's being used when I did a LIST by
ID.. probably best to remove those and re-index.
Chris
> Date: Tue, 26 Nov 2013 13:35:42 -0800
> From: jhes...@
I'm just guessing, but I think the problem is a value mark (ASCII 253) embedded
in the item IDs. The 3rd party backup software we use also balks at backing up
items with value marks in the ID because they're not valid UTF-8 characters.
-John
-Original Message-
From: u2-users-boun...@li
Hello,
I noticed an error when doing a UVRESTORE. We have a UniVerse region with
client information and data. When doing a UVRESTORE I get the following >
Restoring c:\CHRIS/I_CLIENT (21:35:56)
Restoring c:\CHRIS/I_CLIENT/INDEX.000 (21:35:56)
Restoring c:\CHRIS/I_CLIENT/INDEX.001 (21:35:58)
Unab
Kevin,
This is a temporary situation for testing an unrelated issue. When THAT issues
is resolved, I will go back to a single, common DMSECURITY.
This is NOT the problem - PILOT and LIVE are both using the same DMSECURITY
file - PILOT has the problem, but LIVE does not.
The problem is either
Is there a particular reason you can't share that DMSECURITY file across
all SB enabled accts?
On Tuesday, November 26, 2013, Israel, John R. wrote:
> Kevin,
>
> I did an ESEARCH on the DM file, looking for E115. I did not find it in
> MM, but did find it in the following:
> _SB.GENERAL.S
> _SB.
If it's for internal use, I'd set up my own function (or subroutine)
with the one - to - one relationships between each lower case accented
letter and it's upper case equivalent. If the idea is to send info to a
third party, or to use in a different database within you company, be
careful that:
Bob,
I have never been satisfied with MCT so I wrote my own, feel free to use what
you will and add your accented characters logic to it.
SUBROUTINE DAG.MCT(OUT.DATA, IN.DATA)
* MCT - Masked Character Title
* A better option than using UniBasic's MCT Conversion Code
* by David A.
Kevin,
I did an ESEARCH on the DM file, looking for E115. I did not find it in MM,
but did find it in the following:
_SB.GENERAL.S
_SB.LOGIN
_SB.SYSMENU
_SB.USER.CHECK
I did not find it in _MM, but this still looks like progress.
I do not have access to SB source code, but at least this is som
18 matches
Mail list logo