ODBC Error with OE10.1A

We have had a lot of different problems with the SQL92-access on the various 10.x versions, but there is some light at the end of the tunnel, since 10.1C seems to be doing a much better job! We're now for instance able to create tables/columns that are so called keywords. Didn't work in 10.1B, kind of worked in 10.1A, but now it works fine in 10.1C.

Is 10.1C released yet ?

He asks him knowingly ...

What if we can't upgrade the server? We have 10.1a and can't upgrade because of the Datasul ERP. Nevertheless we need to use the ODBC to connect and work with an MSAccess 2007 front-end or Visual Studio 2008 front-end. How do we work-around this problem?

One answer is to beat up on Datasul. There is no reason they shouldn't let you upgrade ... in fact they should be encouraging you to!

Totally Agree with you! The problem as they say is that all their systems have to be re-compiled in the new version and that makes the ERP "not trustable". Thay also say the Structure of the BDs changes from 10.1a to 10.1c or 10.2 (I really don't know if thats true for I don't program in Progress) and everytime we insist on the subject they say there is a fee of US$ xxx,xxx.xx to accomplish the Progress Upgrade with the ERP upgrade...

Nevertheless... we continue like we were and we'll remain so for a long time for we refuse to pay even cent more to these mercenaries. This is the only software company I know that charges for the f*ing upgrades!

But returning to the thread subject... We still hope for a solution from Progress about this.

Anyway, thinking about this problem and how to workaround it, I came to a possible solution. I could connect my SQL Server to the Progress one and publish the Progress tables there.

Where do I find the instructions on how to implement this connection between the two servers? Anybody?

There are really at least three or four different questions here. Are you the same person as the original poster or do you have new information or circumstances? The original post is nearly a year ago. it is certainly not the case that one must upgrade in order to connect with SQL ... just that with each version SQL works better and does more. If you are not the OP, you might want to start a new thread and tell us what you have tried and what happened when you did try and we'll see if we can help.

As for the upgrades, there are several different issues which one really should keep separate.

One is the lamentable practice of APs telling customers that they do not support their Version X product on anything newer than version Y Progress. The supposedly logic for this is that they don't want to have to keep doing regression testing on every past version of their product on every new release of Progress. And, of course, it helps create an incentive for companies to move to newer versions of their product and that makes them easier to support. However, they really go overboard on this and shouldn't get in the way of a customer who is willing to go to the effort to try out a more recent version, do the compiles, run some tests, and give it a go. OK, so perhaps there is no support for this process, but that doesn't mean that the customer shouldn't be allowed to give it a try. Most of the time, a new Progress version is load and go.

A second is the desire by the AP to keep moving customers forward to current versions of their software. This makes them easier to support and should mean they are happier customers because the software keeps improving. The difficulty here is often that there are site specific customizations and this can often mean a need for someone to port those customizations to the new version. Depending on the nature of the customizations that can vary from trivial to traumatic. Most companies, both APs and end-users, don't have very good habits at working in a way that helps to make such transitions easy and the end result, all too often, is that the end user gets stuck on an increasingly old version, getting more and more unhappy, and more and more ready to switch to another package. Switching may well not be the best option, but one understands the emotions which happen here.

I think a third issue is attitude ... on the part of both APs and end-users. APs often talk themselves into thinking that they need all these rules for what can and can't be done and that the right thing for the customer to do in all cases is to upgrade to the latest version which is obviously superior. What they forget is that this relationship should be a partnership and so the AP should be working in a way that helps the end user get what they need and which facilitates a close on-going relationship. End users, for their part seem to focus on how painful the purchase price was, and possibly the maintenance, even though it is generally the case that total cost of ownership of Progress systems is significantly lower than with other technologies. By pinching pennies they end up spending less, but also getting less. If they thought more in terms of return on investment and opportunities for improved effectiveness, they might be more inclined to work better with the AP to make the product better. When I was selling applications, I did 99% of the mods for my customers because I had the technology and expertise to do it efficiently and correctly and thus I could integrate 99% of the enhancements into core product, meaning no problems with upgrades.

End of lecture ....

Hi Thomas

Answer to your question, no, I'm not the same person that started this thread and yes I did started a new thread (which you answered also).

Datasul is a big nonsense, I really don't understand how they gone so far in this business, but I'm not here to discuss their objectives or their practices.

My problem is very real and independent from them. Since their support it's everything but satisfactory we moving along and leave them where they are and hope for they succeed in what ever they plan for their software.

Our client regrets spending sooooo much money in a thing that will die in just a few years.

But as our client moves, we decided to link their new SQL Server with the Progress server and work from there the Datasul DB's. I understood this is possible, in many forums they talk about it but I didn't find any literature on how to implement this between SQL Server 2005 and Progress 10.1a.

After we finish re-develping our clients ERP we'll then decide to upgrade the Progress software to what ever version they could (or have the rights to) but until then if they need to re-compile or just trash the Datasul system won't be of any importance.

Since we having sooo many problems with this pair (Datasul-Progress) many of my developers are evolving a "Progressphobia" which is very sad since it's a fine stable database server, which being my first approach to it I found it very robust.

I plan to start some Progress studies here at the software house but we need time for it (which we don't have), but for the time being we just need to solve our clients problem developing a CRM system to by-pass Datasul's, and the client only wishes Microsoft products from now on (thanks datasul...). So here we are, with an ERP system that we can't upgrade, a database software which we can't upgrade and won't talk to VBA ODBC, a client that won't accept any software but Microsoft's produced software or developed using Microsoft's technology. It's very sad, but life it's made of challenges... so let's move ahead!

We are not Progress developers, but since our client is one of the partners here, we have to dance according to their music and try to do our best now so in the future we could recomend and be heard, which right now won't happend...

So please!

Help me telling me how can we connect to this holy progress 10.1a server (without upgrading it) using ODBC or any other method with a SQL Server 2005 software.

Best regards

jpsilenzi

If relations have broken down with Datasul, then why do you care what they think? If you aren't counting on them for support or upgrades, then just try it on a development platform, do some testing and make the move?

And why involve SQL Server? Is there another application written on it?

Have you considered a DataServer, i.e., pushing the data from Progress instead of pulling it? My understanding is that is a far more robust connection with more flexibility than one can hope for using SQL.

Sounds like there might be a need for some transformation consulting to pick the right path before spending a lot of effort.