SQL Width and Reporting

[BCM]

Do most of you write all reports using Progress 4GL? I am just curious. It would seem that any of the reporting packages available would require ODBC. And ODBC would require the SQL Width to be properly set within the Progress database. But most Progress programmers do not care about the SQL Width because the Progress database will accept any length of character string content.

Personally, I am livid with anger towards Progress for releasing a product that fails to work well in 'normal' work environments in which people work with sofware that does not come from Progress.

If Progress owned the intelligence behind our most popular operating systems (or our most popular anything), then, perhaps, Progress could dictate to the marketplace. However, the majority of users, systems professionals, and business managers in the U.S. have never heard of Progress. Frankly, I don't care what the licensing arrangements are for a developer, if it walks like a duck, talks like a duck, and looks like a duck, it's a duck.

 

[Lee Curzon]

1. Looking back over some of your previous posts, I get the impression you are 'livid with anger towards Progress' full stop.

2. Most Progress programmers do not care about the SQL width, because most Progress programmers use Progress. However I guess it may be a fair criticism that many of us (including myself) are ignorant sometimes of the problems integrating into an SQL world.

3. Any 'systems professional' who has not heard of Progress can hardly be considered professional.

As to your problem:

Firstly, I've never used ODBC as I understand it is very slow, and of course it uses inferior SQL.

I don't know much about SQL-Width either, but rather than fixing your SQL widths on an 'as and when' basis, which I don't doubt is very frustrating, particularly if you need to take the DB offline everytime, perhaps you could write a utility (if dbtool is not flexible enough) to determine which fields are currently fixed incorrectly (by examining the longest data held in them), and run a one-off procedure to fix them. This would obviously be preferable to taking the DB offline several times.

Finally, I will concede, it would be very nice if Crystal reports and the like interfaced easily with Progress. Perhaps other developers can share their experiences?

 

[joey.jeremiah]

how about ado.net or prodatasets in 4gl ( which ofcourse crystal supports )
that's how apps are supposed to be or will be build


that seems to be the overall plan
powerful framework, development tools, language etc.

and a service oriented architecture ( oera )
and powerful features including tight integration with sonic

a real open app, integration with diff apps, platforms,
languages, development, reporting tools etc.

get it open, edge

and ofcourse suitable for a distributed app
over the internet


you can set the sql width and enforce it in the dictionary

by the way the sql engine isn't just for crystal
with the latest sql92 and sql99 advancements

the openedge rdbms will make
a strong option for the java developer community


i hope this doesn't turn into the monthly
i hate progress thread

 

[BCM]

Ok, I'll try not turn this into that particular monthly thread.

The only technical part of my job where I have responsibility but no control is with Progress. Ok, the managers licensed this application before I came along. So, they are partly to blame. But this just does not work like other stuff.

Over the last 7-8 years I have probably gained as much experience as anyone interfacing Progress with other things. But it's far from perfect. Upgrading to version 10 would give us the ability to fix the SQL Width without kicking everyone out of the database. But why should we pay to upgrade to fix something that has been broke?

Further, the group of 'commercial developers' who built the application we have licensed that uses Progress fail to provide sufficient support.

Lee: I do not know where you are from, but in the U.S. very few systems professionals have heard of Progress. Just check with the big oil companies, big accounting firms, big trading companies, Disney, NFL, Pfizer Pharm., etc. The number of systems professionals working in large, enterprise-oriented firms far out numbers those few seat-of-the-pants programmers in small industries with small budgets.

 

[joey.jeremiah]

not alot of people heard about it but alot of them use it
coca cola, pepsi, ford, queen mary 2, at & t, to name a few

including 10,000 application built on progress

alot of it is not progress who ? it's progress who me ?


it's an embedded database that goes in with the application
doesn't require a dba, and rearly, if ever goes down

it's supposed to keep doing it's job and never complain

one customer of ours dry walled their server
they just forgot about it, no one ever needed to maintain it


i don't think it makes alot of sense to think of
the database market as a single big market

progress has a specified market space that they're aiming for


if you're really looking for an open application
you're looking for soa

where progress and sonic, not to mention data direct with xquery
has a substantial edge at

including progress 4gl which is a business application language
and far more suitable for this purpose then java and the likes


but then again i'm still in school ( university ) and just a developer

 

[BCM]

joey.

You make good points.

I'm 55. I've been developing software for 22 years. Systems seem to be about working together and integration. Borland had always offered better quality at a lower price than Microsoft, but IT managers and business mangers tend to choose technology that is more ubiquitous and prolific because it gives them more staffing alternatives.

The companies you mention are probably using Progress apps on the shop floor where integration with office desk tops is less critical. I work in a white collar business, and the back-end data must be available to the business professionals for control, management, and decision making. Every business desk top I have encountered at every firm for the last 15 years has been running Microsoft windows.

 

[joey.jeremiah]

because it's a database that comes with the application ( no separate install ),
doesn't require a dba and very stable

it makes a good selling point for application partners
developing applications on progress

point is it's an embedded database


application partners can also work out arrangement with progress
instead of paying for the products up front

this way they have complete freedom to price the product any way they wish
per transaction, user, department, volume etc.


it's not as if we're talking about ancient host-based app

we use/developed a distributed app with an soa compatible architecture
gui and partial web front-end

and all of our reports are pdf's and office

 

[joey.jeremiah]

by the way joey isn't my real name

doesn't anyone here remember degrassi !!!

 

[Lee Curzon]

Until you mentioned it the other day, I'd never heard of degrassi - it's some sort of Canadian TV programme I understand.

I presume you're a fan.

Out of interest, your name isn't David is it?

 

[BCM]

Hey, Lee, now I know you're not from the U.S. "programme". :awink:

 

[Lee Curzon]

"seat-of-the-pants programmers in small industries with small budgets"

Must remember to put that on my CV.


BCM,

I can understand your frustration at having to integrate a difficult child. From our side of the fence (or at least from my POV), it is frustrating that my experience with the excellent 4GL doesn't do much for me if I ever want to cross over to or integrate with MS. I accept that Progress is the odd one out, but as far as Business Logic goes, it just seems a hell of a lot better, and easier than SQL.

Maybe it's just lack of experience with SQL I don't know.

Anyway, I'm looking forward to investigating the new OE10 <> .Net architecture over the next year or so.

 

[Lee Curzon]

Hey, Lee, now I know you're not from the U.S. "programme". :awink:

Hah! Got me.