Search results

running ipcs from the account I've always used shows the owner for the shared memory segment of the process running the db I am trying to check (using that cross reference suggestion you made to locate the shmid) is root with perms=644 and nattch=14 (I don't know what perms and nattch are)...

My employer is still only in the evaluation phase of QAD 2016 which uses Progress 11.6. For my need today the I might be able to use that evaluation database. For longer term knowing the 11.5 requirement might give some workaround. I'll explore that later. But for right now, it seems I need to...

ODBC generated an error on my environment when I tried to connect after I added this option to the DSN [DataDirect][ODBC Progress OpenEdge Wire Protocol driver][OPENEDGE]Invalid Connection Property in Connection Property string The ODBC driver is the one you can currently download from QAD...

Yeah, I'm sure it does once I learn exactly how to use it and why the way I am using it doesn't work. ;-) It seems to be too critical a tool not to. I think I saw somewhere that QAD has a menu option somewhere to run dbtool on its data. I will search for that.

I do not understand how either of those Progress KB's will get ODBC to read (at least correctly) the data in the progress database.

OpenEdge version is 10.2B07 on Red Hat Enterprise Linux Server release 6.5 I did not realize that dbtool does not display any error messages on screen when it fails. So I found that it created a file called mydatabasename.lg When I looked there it gave me the idea that maybe I haven't...

I ran dbtool and it appears to do nothing. As soon as I give an answer to the prompt about verbose level, I IMMEDIATELY get back to the linux prompt as if the tool has run and done everything in a nanosecond. It is actually doing nothing as I the ODBC error messages continue. I also noted that...

"Architecture mismatch" means one program in the chain of ODBC related programs communicating with another is 32 bit and an adjoining one in the chain is 64 bit. Which are the programs that can't talk and what to do about this is situation specific. For example, I got this when using Visual...

Apparently this is a bug in SQL Server (or the ODBC driver). I found a workaround (that worked for someone getting a similar message accessing SalesForce): Select * From OpenQuery(mylinkedserver,'select top 10 * from sysprogress.systables') I got a different error when accessing pub._file...

As a general rule, it is always best to run an English version of your software when you need to debug an error message so you can get the English version of that error message, and then Google that message. There are FAR more people debugging errors in English than there are in German (or any...

Since the inception of ODBC, critics have argued about version issues and testing. On the bright side, if you are only reading data using ODBC, any bugs created by version incompatibility will probably be less obscure. Simplest shortcut is likely the above answer (use the latest version of an...

Both of these failed: select top 10 * from mylinkedserver.mydatabase.sysprogress.systables select top 10 * from mylinkedserver.mydatabase.pub._file error message for 1st one: Msg 7356, Level 16, State 1, Line 3 The OLE DB provider "MSDASQL" for linked server "mylinkedserver" supplied...

The code the linked server-based UI is using must not be generating the right syntax, because when I write my own query manually that uses the 4 part table naming (the first part being the linked server name I created) then it does retrieve data as expected. Well, that's certainly far less...

Since it is clear to me that making use of ODBC will be a long term good thing for us, I am now installing the licensed ODBC driver for Windows that comes with with our QAD product and then I will try following up on your idea about the linked server generated SQL.

Hmmm. SQL Server generated the SQL statement, I just clicked in the UI to get it to show me data. I will double check to see what SQL it is generating. Thanks for the link.

The simple ODBC test connection works. The simple linked server test connection works. I can get a list of tables using that linked server. Outside of SQL Server, I can write a powershell script that does a select * from sometable. I cannot get a Select * from [whateverlinkedtable] to work...

At some point I will also figure out if there are some connectivity tools I can use like ODBC. At that point I'll likely try using SQL Server's Linked Servers since I'm more familiar with the querying tools in that environment.

The Data Digger developer suggested the same thing. Great minds think alike. I am downloading it now. Not a small footprint solution, but it has other advantages. :-)

So if I have a runtime of Progress on Windows, I can use this (I don't think our QAD has a Windows version of Progress, the client seems to be browser only). But I could be wrong. But if not, I need to search for a Progress windows runtime. It looks like ProKB includes a runtime, so maybe if I...

Does this run on Linux? (One without a GUI environment installed on it) Or do I need to put this on Windows and find a simple way to get my windows desktop to talk to the Progress db on the Red Hat server?