Yes, it's using the ODBC driver that came on the middleware disk with
Unidata 7.1.
Drew
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Houben
Sent: Thursday, April 03, 2008 6:50 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData and
Following up on the common thread, can one OPENSEQ to a COMMON variable?
-Original Message-
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
quote who='Dennis Bartlett' date='Friday 04 April 2008'
Following up on the common thread, can one OPENSEQ to a COMMON variable?
Sure - same approach.
OPENSEQ FILE,RECORD TO F.HANDLE THEN
* add F.HANDLE to the common array and list of open files...
END
--
Jeff Butera, Ph.D.
Administrative
Hi,
Depending of the U2 version ... A well known bug occurs when
reading/deleting, a great (tens of Mo) record of type 1 or 19 file. Use
VLIST for your FREE.LOC basic.
Regards.
Christian PAGER
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Doug Chanco
Dennis Bartlett wrote:
Following up on the common thread, can one OPENSEQ to a COMMON variable?
Absolutely.
COMMON is merely a method of sharing data between programs without
argument passing as is commonly done with subroutines. Note that common
in this fashion is accessible among
Yes, but be sure to re-initialize to '' AFTER closing, if you close it,
at least in UniData.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dennis Bartlett
Sent: Friday, April 04, 2008 8:07 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] COMMON
And be very careful with 4GLs using named common, as I found out many years ago
with PACE. It stored filepointers in named common, generating the common name
from the file name.
Fortunately we found the problem when the runtime complained of a redefinition
of common (one routine had the same
Yes, but
On thing to remember - OpenSeq sets a record lock.
That will remain until you CloseSeq the record.
If the file is unique to your user number, for example, you might want to
release it rather than have a load of these clogging up your lock table. One
of the few occasions when locking
With file pointers, the trick is to set flags so that you know that
they're open or closed.
Actually there is a way to test if a variable is an open file-handle or
not ( at least in uv):
I have the following code in som subroutines that you can feed with a
open file handle or a file
I would think that you wouldn't have a problem unless any of the following
occurred:
1. You had international characters or control characters embedded in your file.
2. They insisted on one of the 16-bit Unicode variations (UTF-16).
In the first case, you could cleanse your file before
I have gotten that error when trying to open (or LIST) a record that is too
large (such as a PH record with millions of lines) or when loading an
internal variable with too much data before writing it to a file (e.g. many
instances of var-1 = line). Using WRITEBLK or WRITESEQ solves the latter
quote who='Mats Carlid' date='Friday 04 April 2008'
With file pointers, the trick is to set flags so that you know that
they're open or closed.
Actually there is a way to test if a variable is an open file-handle or
not ( at least in uv):
I have the following code in som subroutines
David -
The UniVerse Administrative and SQL users must have a password in
order to be valid. Users who do not have a password cannot administer
UniVerse. This applies to both the administrator on Windows and the
root user on unix/linux.
Add a password to the user you are having trouble with
Hi Ken
The user NT AUTHORITY\System is an internal windows user name. It is part
of the internals of windows and adding a password to it could cause all
sorts of things to stop working. It is not a login name, hence I am not
sure why it is now being used as the default SQL DBA in universe on
David -
Install instructions for UV on Unix states that you need a uvsql user
for this purpose which needs to be setup prior to the installation.
Have you checked the Windows installation instructions in the UV
docs. You might not have setup the default user prior to the installation.
Ken
Hi Ken
With windows the installer was the default SQL Account, which is usually the
administrator. It is in updating to the new release that has changed the
way things have been done. My actual issue is that UniVerse no longer
recognises current SQL users, the only thing I can see is that the
Hi David -
Did you do the upgrade with a different user that the original
install? If so, uninstall UniVerse and re-install it. It should leave
all your user stuff alone, and after the new install, instead of an
upgrade, things should be fine. You should however, logon to each
account as the
Hi Ken
1. I did install as the same user
2. You are right that the domain name is case insensitive in windows,
however it appears UniVerse is case sensitive when check against UV_USERS
for valid SQL Users.
3. Security of the directories are OK.
I eventually uninstalled UniVerse and reinstalled.
It's a problem with other applications too. We had the exact same
problem with another third-party packaged application. The problem is
Windows allows you to define David and david to mean the same thing.
But to application software, these are two different users - unless the
third-party
19 matches
Mail list logo
