UserID Error in Procedure Editor (Alter Statement)

[slh]

Hi everyone,

I tried to experiment in SQL-89 for procedure editor using Alter statement as follows:

ALTER TABLE edi_table
ADD Column table_size INTEGER
Label 'table_size'.

However I got error message when trying to execute the statement using F2.

Blank UserId is Invalid.(957)
Could not understand Line 2.(196)

 

[Casper]

Dont use this. its a deprecated feature.

 

[RealHeavyDude]

The issue with the SQL-89 that you can run with the procedure editor is that it isn't really SQL. Instead it's compiled on-the-fly like any other 4GL statement and executed on the 4GL engine. It should have been eliminated from the product as soon as the support for SQL92 with a dedicated SQL92 engine on the database was added - which was around 1998 when V9 reared it's ugly head ...

If you really want to use the Progress/OpenEdge database with SQL than you should upgrade to a recent OpenEdge 10 version and connect to the database via the ODBC/JDBC drivers provided by Progress with a environment that supports ODBC/JCBC connections of your choice.

Heavy Regards, RealHeavyDude.

 

[slh]

Dont use this. its a deprecated feature.

Hi Casper,

I understand, but thats what is available to me currently.

 

[RealHeavyDude]

You don't say what version of Progress/OpenEdge this is and whether the database is used by an ABL application or SQL application or both. What is also important is how the table was created in the first place. If it was created via SQL, depending on the version you are running, there might be no way to change it from the ABL side ( procedure editor ).

Heavy Regards, RealHeavyDude.

 

[slh]

Hi,

Thanks for fast response. I am using version 9.1B, table created using Data Dictionary.

As far as it is currently, no one is accessing the table. From database perspective, there are other procedure accessing it (but definately not edi_table)

 

[RealHeavyDude]

Then your only option is to modify the table ( add the field ) from the 4GL. For that you can either edit the table definition directly in the data dictionary tool or you can load a delta definition file in the data administration tool. You need to be aware that this modification of the database schema can only be done when no other process is holding a schema lock ( yes 9.1B is very, very, very old to say the least ). In practice this means that you can apply this change only when nobody else is connected to the database.

Heavy Regards, RealHeavyDude.

 

[TomBascom]

Don't do that.

Using SQL from within the 4GL is only going to lead to pain and misery. It does not get any better. Ever.

 

[medu]

Is it just me or there are an increasingly number of peoples that tries to hit Progress using SQL from within procedure editor? I can understand if they were doing this from another language for user interface or simply for accessing some data but this looks like they've were either only left with the Progress database and someone stolen the 4GL application while they were slipping or they had to bring in new guys but did not considered any training

I've never saw any Progress application that does inline SQL statements so far but that could come to an end... the fact that peoples not familiar with 4GL use SQL for data access it's something that it's understandable but definitively not the 4GL way, is there anyone using SQL statement inside plain 4GL code in real life applications?

 

[slh]

Is it just me or there are an increasingly number of peoples that tries to hit Progress using SQL from within procedure editor? I can understand if they were doing this from another language for user interface or simply for accessing some data but this looks like they've were either only left with the Progress database and someone stolen the 4GL application while they were slipping or they had to bring in new guys but did not considered any training

I've never saw any Progress application that does inline SQL statements so far but that could come to an end... the fact that peoples not familiar with 4GL use SQL for data access it's something that it's understandable but definitively not the 4GL way, is there anyone using SQL statement inside plain 4GL code in real life applications?

Hi Medu,

Appreciate your quick response and insights providence. I do admit that PRogress 4GL is something totally new to me in which I had just took over. Unfortunately, many a times we were given on the job training.

 

[RealHeavyDude]

The fact is that the Progress database has never been a SQL database in the first place. Over time and releases they have added more and more SQL support but still it is no SQL database it just got closer . Whenever you access it via SQL you face limitations because the natural way to talk to it is the ABL ( or 4GL as it was called in the past ). Therefore I totally understand people not familiar with Progress trying to access it with the embedded SQL-89 that can be run from the procedure editor - because most of the times the "real" SQL-92 access to the database has never been configured and most are not even aware of that. The only solution from my point of view is:

1. Configure the database for SQL-92 access ( start a dedicated secondary login broker on the database and configure SQL security accordingly ).
2. Access the database with the ODBC/JDBC drivers provided by Progress ( AFAIK they are included in every runtime license ) and use a tool capable of handling ODBC/JDBC connections of your choice.

Information on how to accomplish this can be found in more than one thread on this forum.

Heavy Regards, RealHeavyDude.

 

[slh]

The fact is that the Progress database has never been a SQL database in the first place. Over time and releases they have added more and more SQL support but still it is no SQL database it just got closer . Whenever you access it via SQL you face limitations because the natural way to talk to it is the ABL ( or 4GL as it was called in the past ). Therefore I totally understand people not familiar with Progress trying to access it with the embedded SQL-89 that can be run from the procedure editor - because most of the times the "real" SQL-92 access to the database has never been configured and most are not even aware of that. The only solution from my point of view is:

1. Configure the database for SQL-92 access ( start a dedicated secondary login broker on the database and configure SQL security accordingly ).
2. Access the database with the ODBC/JDBC drivers provided by Progress ( AFAIK they are included in every runtime license ) and use a tool capable of handling ODBC/JDBC connections of your choice.

Information on how to accomplish this can be found in more than one thread on this forum.

Heavy Regards, RealHeavyDude.

Hi Dude,

Appreciate your help, side track the issues a little. My main application design button for user to exit the application entirely. HOWever, when I setup local application by copying all w/ p files, my application always redirect application exit to a procedure editor instead of totally shut down the program! Wonder why has it gotten this behaviour.

 

[RealHeavyDude]

You might want to have a look into the following thread

http://www.progresstalk.com/showthread.php?118841-Progress-Application-Exit-with-Procedure-Editor

Heavy Regards, RealHeavyDude.