ODBC Woes :(

NeHe

New Member
I really need some help linking to a progress database using Microsoft Access 2002 (xp).

Server: Win2K
Progress: 9.1CODBC: Merant 3.7
App: Microsoft Access 97/2000/2002

We have gone through all the channels. First our software supplier. They are still working on the problem (6 months later).

Second we spoke with Frontstep. They supply support for Syteline and apparently want nothing to do with ODBC issues.

Finally I spoke with Datadirect. They suggested every driver from the Intersolv driver, to the latest 3.7 driver.

We have tried all these drivers, we have opened (honestly) hundreds of support cases. We have given these guys every bit of information possible.

And on top of all that, techs have been out to look at the problems, but have left... never to be heard from again.

This is extremely frustrating!

Problems: Two tables ARTRAN and MATLTRAN have values higher than the field definition, this blows us up every time.

We open a table and it displays a bit, then after a few seconds crashes access.

If we jump to the end of a table it crashes access.

We open a table and it opens with #name in every field.

We open a table and it opens with #deleted in every field.

But yet the test connection works every time.

Also, dumping the data into a table with VB code works every time.

Finally, using a .UDL connection to the database works every time with every table when importing data into a program such as Excel.

The broker is running the ports are correct. All environment variables that need to be set are set... the system has been analyzed by outside "progress" techs from the company that sold us the software.

Opening a linked table in access blows up more than 50% of the time.

Initially it seemed to be a user issue... during mid day when alot of users are working in the system crashes happen more often. Later in the afternoon when everyone has gone home connections work about 75% of the time.

All we need / want is a stable connection. To rewrite the access application using code would be slow and ALOT of work (hundreds of queries).

Can anyone help? I am willing to pick up the cost of a call... email, sample code, anything?

I'm frustrated, our company is frustrated. We have exhausted our support with the three mentioned companies.

If you need any further information, please email me.

Also interested in getting a connection using .ASP... I get a very odd error that seems to be discussed often on the web. (extra parameter not allowed). No solution.

nehe@connect.ab.ca
 
We use Merant SQL link drivers (not the ones that come with Progres) with Progress and business objects.

It sort of works.

Might be worth a try.
 
PS If you do a search on here about ODBC you will find a general gloom about it.

It hasn't really worked at alll in the previous version of Progress and it only sort of works in the latest.

Progress pull your finger out and stop farting around with dumb objects!
 

NeHe

New Member
SQL Link

Actually we have tried the Sequelink drivers... Datadirect said because it uses a client server environment that we should have better luck. Unfortunately, this was not true in our case :(

Now that we are running the 9.1C version of progress Datadirect doesn't want us using anything other than the 3.7 driver. Unfortunately, our supplier doesn't have any plans to support it even though it came with the package. They told us it would work, and then left us high and dry.

I really don't care how we connect to the data, although I'm assuming ODBC is the only option.

If I could get any type of stable connection I'd be very happy! I don't care how it's done, whether it's supported, etc.

Someone out there has to have had success... ?

I'd even settle for a connect using .asp. At least then I could get some reports done. However, the example code floating around the net did not work for me. I get the dreaded parameter not allowed error when attempting to open the connection.

The last crazy idea frontstep gave us was to create a second database that contained all the tables we needed for our reports. Set the field sizes is this database to match the data in the database, and have triggers in Syteline update both tables at the same time.

Can you imagine the overhead of doing this!?! Syteline runs poorly enough as is!

I'm not even sure that would solve the connection failures... I think all that would do is prevent ARTRAN and MATLTRAN from blowing up.
 

NeHe

New Member
The field width is one of the problems, unfortunately, our software supplier doesn't want us to modify the width, and if we send it to them to modify it will cost us a small fortune. They claim it takes 3 1/2 hours to recompile everything whenever a small change is made to any screen (new UET for example).
 

RichardThorp

New Member
This is interesting, as for one of the datatypes (I cannot remember which), Progress' default SQL-WIDTH is only 1/2 what it should be.
 

NeHe

New Member
Unfortunately, I have been unable to get OpenLink to connect. I'm not really sure what it is that I'm doing wrong. I can set up the 3.6 and 3.7 drivers with my eyes closed, but with OpenLink I'm lost.

I followed the Progress ODBC faq to the last detail, as well... I printed off a few posts from the net. I went through all the settings... I checked all the environment variables... I even retested the 3.7 connection.

When I test connect using the OIB name for the Port, it looks as if it's trying to connect, and then it locks (program is not responding). If I use the oib number 10400, same problem.

If I use the database number 10000 for the Port, it says something along the lines of "exceeding permissable connections"..

Also, our database doesn't have a default account, so there is no username / password.
 
U

Unregistered

Guest
Now you know why Progress is so cheap. Good DB, but a bit too proprietary to itself and incompatible with third party vendor applications requiring good ODBC or JDBC connectivity.

Theres a reason why DB2 or SQL serv cost a bit more. Integration, tools and ecxellent IDE apps.

Sorry to slam, but Progress software "progress" in these areas are bad and all we get for it is a company falling back on open source for its development.
 

RichardThorp

New Member
What platform is your server, and what is the network speed between server and client?

Are you using a SQL-89 connection (using the oibrkr32.exe/_prooibk process) or SQL-92.

If it is SQL-92, it is the SQL username/password, not the Progress security username/password - try logging in as SYSPROGRESS
 

NeHe

New Member
Server is Win2K, the connection is 100BaseT Switch. Connection to the other half of the building is fiber.

We are using the old oibrkr32.exe / _prooibk process

:(
 

RichardThorp

New Member
Hmmm. Any particular reason you are not using SQL-92? Just set another login server in the Progress explorer to listen for SQL-92, login as SYSPROGRESS to create users/set permissions and away ya go (theoretically). I have found that the performance is a lot better, and it could help - it sounds like you are just returning too much data under SQL-89 for it to be reliable.

Certainly worth giving it a shot anyways.
 
U

Unregistered

Guest
ADO?

Have you tried using ado with access. Been fairlyr reliable for us other than scanning large tables.
 

RichardThorp

New Member
I am currently using com automation to populate an Access database for reporting purposes. However, the population period is v.slow. (e.g. my for eaches take a total of 25 minutes to completely process; adding in the code to write to access means the process takes over 5 hours for the same for eaches).

Is ADO another technique, or is it just me getting confused with my TLA's?

Thanks

Richard
 

kidehen

New Member
OpenLink Software, Inc. has provided usable ODBC Drivers for Progress since 1993.

All I can say is simply go to http://www.openlinksw.com to download high-performance and functional drivers for Progress (this includes new SQL-92 Drivers).
 
Top