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
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.
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
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.LOGIN
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
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)
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:
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:
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
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.org
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
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 for
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
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
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 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
ALLOWMARKS in uvconfig??
JayJay
On 26 Nov 2013, at 16:15, Chris Austin cjausti...@hotmail.com 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
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
18 matches
Mail list logo
