I am getting this beauty of an error message when connecting to a newly created "restored" database
System.Data.Odbc.OdbcException was unhandled
ERROR [HYC00] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Optional feature not implemented.
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver][OPENEDGE]Server rejects connection on attach.
ERROR [IM006] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Driver's SQLSetConnectAttr failed.\r\nERROR [HYC00] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Optional feature not implemented.
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver][OPENEDGE]Server rejects connection on attach.
ERROR [IM006] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Driver's SQLSetConnectAttr failed.
What is amusing this is the same test code I used to connect to my sports2000 database that "works" I get this error during the connection.open()
would this happen to be related to a .st file that has the following?
d "Schema Area":6,64;1 . d "data32":7,32;64 . d "index32":8,1;8 . d "data64":9,64;64 . d "index64":10,1;8 . d "data128":11,128;64 . d "index128":12,1;8 . d "data256":13,256;64 . d "index256":14,1;8 . d "LOBS1":15,1;512 . d "LOBS1_index":16,1;8 .
No. The structure of the database is completely transparent to any client connecting and querying the data. The data, however, is a completely different beast. If you are accessing a table that contains LOBs then you will probably be getting this error.
Try accessing a table that does not contain LOB types and see if that works.
Thank you for providing me a tip but the error is being thrown when I attempt to connect to the database using the ODBC connection string. No table or SQL queries.
perhaps my problem is because I am first restoring a database from a backup and I may not have someting correct with the restore?
it appears the prorest does not work correctly when you run it with paths. For example.
if i cd into c:\progress\openedge\bin and run c:\prorest c:\OpenEdge\wrk\myDb c:\backup\234 the prorest will create the .st and db file in the target path but the rest of the db restore is created in the c:\progress\OpenEdge\bin directory. I am testing this out by running the prorest relative to the target directory I want to restore the database into.
Ah..
When running any of the Progress utilities, you should be in the directory that the DB exists in and run /proenv from your working directory - this will set the correct parameters and you can then run the relevant commands without needing any pathing infromation.
With respect to prorest, it will create the databsae only if one does not exist. If a DB exists, it will restore into that DB. If a .st exists, it will use the information in the .st to restore the DB, but this will be relative to the current directory, unless the .st has absolute paths inside. If the .st has relative paths, lines ending with a . (period), then it is relative to where you are running the command and which is why the extents are created in the current directory.
Does the databse log (.lg) file have any relevant entries regarding your connection attempt?
nope, that was not the problem. After getting my database files all in the same location I still have the same error.
The log does have my login attempt
[2010/10/01@09:16:15.265-0500] P-2432 T-1836 I SRV 1: (8873) Login usernum 24, remote SQL client.
[2010/10/01@09:16:15.281-0500] P-2432 T-1836 I SRV 1: (7129) Usr 24 set name to administrator.
[2010/10/01@09:16:15.281-0500] P-2432 T-1836 I SRV 1: (453) Logout by administrator on .
but that is as far as the program gets before the exception is thrown on this database.
The issue with the ODBC connection was the following. The database has a user table with users populated. We need to use a user that exists in the user table to connect to the database.