RE: [U2] UniData and Unicode
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 Unicode What ODBC driver are you using? Is this Id Works using Unidata ODBC to retrieve data from Unidata? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Henderson Sent: Thursday, April 03, 2008 3:28 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData and Unicode All, Thanks for the information you've provided. We've received some additional comments from the Id Works vendor. They have indicated that the earlier versions of their software only required ODBC compliance (with various conformance levels: core, extended grammar, etc.), but that the current versions require ODBC Unicode compliance. If it is not - by default - ODBC Unicode compliant, can it be configured to be so? Thanks, Drew --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] COMMON
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/
Re: [U2] COMMON
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 Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 Where I'm from, we believe all sorts of things that aren't true. We call it history. The Wizard, Wicked --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] error question
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 Envoyi : vendredi 4 avril 2008 03:35 @ : u2-users@listserver.u2ug.org Objet : [U2] error question Hey all, I am pretty sure this is a out of memory/stack space type error but I was hoping someone could tell me where I can find the fault types and if there is a way to use the address that the error returned to get where the code was when it blew up? below is the error Abnormal termination of UniVerse. Fault type is 11. Layer type is BASIC run machine. Fault occurred in BASIC program FREE.LOC at address 4c4 Thanks all dougc --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] COMMON
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 programs for the individual user, not to be confused with shared common, (such as the catalog uses, which allows users to access the same info). So, any variable can be stuffed into a common block, and it's best to use what's called NAMED COMMON so that you don't collide with anyone else's definitions, (particularly if you're running vendor code which you can't read the source code to). And then any program or routine that has that COMMON block defined within it has acccess to the variables within it. With file pointers, the trick is to set flags so that you know that they're open or closed. Which can be followed through to other variables, set flags to show that they've been initialized or not. Always set them to show non-initialized first, set them, set the flags, then in any routine that uses them, check the flags before you use them, and if the flags aren't set, you can't use the values. One very common way of dealing with this is to call a program from the VOC LOGIN PA which sets common. As has been mentioned previously, watch out for accounts, as showing that your PAYMASTER file is open, and having your user log from TEST to LIVE will give you some very real problems... -- Allen Egerton aegerton at pobox dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] COMMON
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 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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 name declared twice), and not by two programs confusing one declaration and thereby writing to the wrong file! Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen Egerton Sent: 04 April 2008 14:00 To: u2-users@listserver.u2ug.org Subject: Re: [U2] COMMON 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 programs for the individual user, not to be confused with shared common, (such as the catalog uses, which allows users to access the same info). So, any variable can be stuffed into a common block, and it's best to use what's called NAMED COMMON so that you don't collide with anyone else's definitions, (particularly if you're running vendor code which you can't read the source code to). And then any program or routine that has that COMMON block defined within it has acccess to the variables within it. With file pointers, the trick is to set flags so that you know that they're open or closed. Which can be followed through to other variables, set flags to show that they've been initialized or not. Always set them to show non-initialized first, set them, set the flags, then in any routine that uses them, check the flags before you use them, and if the flags aren't set, you can't use the values. One very common way of dealing with this is to call a program from the VOC LOGIN PA which sets common. As has been mentioned previously, watch out for accounts, as showing that your PAYMASTER file is open, and having your user log from TEST to LIVE will give you some very real problems... -- Allen Egerton aegerton at pobox dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] COMMON
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 could become a hindrance rather than a help. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Bartlett Sent: 04 April 2008 13:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] COMMON 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] COMMON
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 name in FN: IF FILEINFO( FN,0) THEN ;* He gave us an open file-handle. FP.FN = FN FNAM = FILEINFO(FN,1) END ELSE OPEN FN TO FP.FN ELSE ERR.M = Me:: Can't open :FN RETURN END FNAM = FN END Every other test I've tried results in error messages. This may be universe only - don't know. -- mats --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData and Unicode
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 transferring. The issue here is that you may be transferring bytes that are not valid for the UTF-8 encoding. In the second case, you would have to talk to IBM, as, to my knowledge, the current ODBC drivers (I wrote the original Unidata driver's base code many years ago) treat all chars as one byte. They may have completely rewritten that code, but I doubt it... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Henderson Sent: Friday, April 04, 2008 5:06 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData and Unicode 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 Unicode What ODBC driver are you using? Is this Id Works using Unidata ODBC to retrieve data from Unidata? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Henderson Sent: Thursday, April 03, 2008 3:28 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData and Unicode All, Thanks for the information you've provided. We've received some additional comments from the Id Works vendor. They have indicated that the earlier versions of their software only required ODBC compliance (with various conformance levels: core, extended grammar, etc.), but that the current versions require ODBC Unicode compliance. If it is not - by default - ODBC Unicode compliant, can it be configured to be so? Thanks, Drew --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] error question
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 problem. I doubt if you'll be able to find the line in the program where that happens. I don't think even ON ERROR will report anything before you are kicked out of UniVerse. -- Louie --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] COMMON
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 that you can feed with a open file handle or a file name in FN. This may be universe only - don't know. Works on Unidata as well. -- Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 Where I'm from, we believe all sorts of things that aren't true. We call it history. The Wizard, Wicked --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] problem with UniVerse SQL Users on windows
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 and see if that fixes the problem. Ken At 06:53 PM 4/3/2008, you wrote: UniVerse has made NT AUTHORITY\System the default DBA, but as this has no password as an internal user, I cannot login as NT AUTHORITY\system to create a new SQL User. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] problem with UniVerse SQL Users on windows
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 windows. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] problem with UniVerse SQL Users on windows
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 At 01:00 PM 4/4/2008, you wrote: 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 windows. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] problem with UniVerse SQL Users on windows
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 domain name is in a different case to that which is stored on UV_USERS in the SQL Catalog. The second issue, is that it does recognise current SQL users, I have no SQL DBA access to UniVerse to resolve issues. Hence locked out. Regards David Jordan Managing Consultant 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 At 01:00 PM 4/4/2008, you wrote: 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 windows. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] problem with UniVerse SQL Users on windows
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 administrator who did the install to auto run UPDATE.ACCOUNT. Also, the domain name is case insensitive in Windows authorization. Also, it may be a permissions issue after the update. I have had this type of problem with a Unix update. Check all the permissions on the UniVerse files, especially in the .uvhome/uv/bin directory. Hope this helps. Ken At 03:28 PM 4/4/2008, you wrote: 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 domain name is in a different case to that which is stored on UV_USERS in the SQL Catalog. The second issue, is that it does recognise current SQL users, I have no SQL DBA access to UniVerse to resolve issues. Hence locked out. Regards David Jordan Managing Consultant 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 At 01:00 PM 4/4/2008, you wrote: 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 windows. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] problem with UniVerse SQL Users on windows (Domain name is now case sensitive)
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. Now in UV_USERS all domain names are in uppercase and it recognises SQL users. Problem: IBM is making domain name case sensitive and this will effect anyone upgrading where domain names are in lowercase in SQL_USERS. Regards David Jordan Managing Consultant [EMAIL PROTECTED] Mobile: 0428 669 730 Phone: 61 2 9418 8329 Fax: 61 2 9427 2371 PO Box 909 Lane Cove NSW 2066 Australia www.dacono.com.au CAUTION: This email and any attachments are confidential, may be privileged, and are intended for use solely by the addressee. The confidentiality and/or privilege in this email is not waived, lost or destroyed if it has been transmitted to you in error. If you receive this email in error, please notify Dacono by reply email immediately, delete the email and destroy any printed copies. You must not disclose, disseminate, distribute, reproduce or use the information contained in this email which may contain intellectual property or copyright irrespective whether you are or are not the intended recipient. The content and opinions contained in this email are those of the individual sender and may not necessarily reflect the views and opinions of Dacono. Dacono does not guarantee that this email is free from viruses, errors, interception or interference. Use of this email and any attachments is at the sole risk of the user. Dacono does not accept any liability for any loss or damage to your computer system or network (including any consequential damage) which may occur directly or indirectly from the use of this email. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Ken Hall Sent: Saturday, 5 April 2008 10:49 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] problem with UniVerse SQL Users on windows 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 administrator who did the install to auto run UPDATE.ACCOUNT. Also, the domain name is case insensitive in Windows authorization. Also, it may be a permissions issue after the update. I have had this type of problem with a Unix update. Check all the permissions on the UniVerse files, especially in the .uvhome/uv/bin directory. Hope this helps. Ken At 03:28 PM 4/4/2008, you wrote: 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 domain name is in a different case to that which is stored on UV_USERS in the SQL Catalog. The second issue, is that it does recognise current SQL users, I have no SQL DBA access to UniVerse to resolve issues. Hence locked out. Regards David Jordan Managing Consultant 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 At 01:00 PM 4/4/2008, you wrote: 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 windows. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] problem with UniVerse SQL Users on windows (Domain name is now case sensitive)
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 application bothers to force/translate the user-ID always to uppercase -- it's going to be an on-going issue. I guess to multiplatform applications, they need to make an exception for UNIX, as it allows mixed case user-IDs (I've yet to ever see one though!). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jordan Sent: Saturday, 5 April 2008 12:19 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] problem with UniVerse SQL Users on windows (Domain name is now case sensitive) 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. Now in UV_USERS all domain names are in uppercase and it recognises SQL users. Problem: IBM is making domain name case sensitive and this will effect anyone upgrading where domain names are in lowercase in SQL_USERS. Regards David Jordan Managing Consultant [EMAIL PROTECTED] Mobile: 0428 669 730 Phone: 61 2 9418 8329 Fax: 61 2 9427 2371 PO Box 909 Lane Cove NSW 2066 Australia www.dacono.com.au CAUTION: This email and any attachments are confidential, may be privileged, and are intended for use solely by the addressee. The confidentiality and/or privilege in this email is not waived, lost or destroyed if it has been transmitted to you in error. If you receive this email in error, please notify Dacono by reply email immediately, delete the email and destroy any printed copies. You must not disclose, disseminate, distribute, reproduce or use the information contained in this email which may contain intellectual property or copyright irrespective whether you are or are not the intended recipient. The content and opinions contained in this email are those of the individual sender and may not necessarily reflect the views and opinions of Dacono. Dacono does not guarantee that this email is free from viruses, errors, interception or interference. Use of this email and any attachments is at the sole risk of the user. Dacono does not accept any liability for any loss or damage to your computer system or network (including any consequential damage) which may occur directly or indirectly from the use of this email. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Ken Hall Sent: Saturday, 5 April 2008 10:49 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] problem with UniVerse SQL Users on windows 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 administrator who did the install to auto run UPDATE.ACCOUNT. Also, the domain name is case insensitive in Windows authorization. Also, it may be a permissions issue after the update. I have had this type of problem with a Unix update. Check all the permissions on the UniVerse files, especially in the .uvhome/uv/bin directory. Hope this helps. Ken At 03:28 PM 4/4/2008, you wrote: 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 domain name is in a different case to that which is stored on UV_USERS in the SQL Catalog. The second issue, is that it does recognise current SQL users, I have no SQL DBA access to UniVerse to resolve issues. Hence locked out. Regards David Jordan Managing Consultant 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 At 01:00 PM 4/4/2008, you wrote: 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 windows. Regards David Jordan --- u2-users mailing
