Is using define temp-table with a like option bad coding standards?

[progdev1]

Hi does anyone know is using define temp-table with a like [database table] option considered bad coding standards in PROGRESS ABL. I have never heard this before and am wondering if anyone else has ever heard this. One of the person I work with consideres it bad. If the database has to change then the code has to change. Where as I would consider it good for the same reason. i.e. if you are changing the database then you need to review the code that the database affects anyway. I'm am just wondering what the general conensus is here before i say anything.

 

[Cringer]

I've come across people who consider it to be bad practise too. The argument of db change needs code change is a rubbish one in my opinion as a db change that would change things that considerably would need code changes anyway, surely?

More generally though, I think it depends on what you are trying to achieve. If you are trying to devolve database access from w code for example, then defining a temp table like the db table is almost imperative IMO. In that case you can just pass the temp table to the pcode that manages the db updates and you've got everything you need there for a buffer copy.

If on the other hand you only need a couple of fields from a massive db table, then defining the tt like, is a massive waste of resources. As with most things it's a judgement call.

 

[GregTomkins]

With respect, "if you are trying to devolve database access from w code for example, then defining a temp table like the db table is almost imperative IMO" is rubbish in my opinion. On the contrary, the TT's that I see passed to a .W more often than not are an aggregation of bits and pieces of different tables, collected into one place so that the .W doesn't have to know about all those messy details. As a general principle, I think you want all the detailed knowledge of tables and fields and the internals of your app centralized on the server side. The .W should, to the extent practical, strive to merely display things.

That said, I don't think there is anything absolutely wrong with LIKE, but personally, I don't like (no pun intended) the way it obscures the structure of the table in the source. But that's not a big deal. In any event, I only use it when I truly need an exact replica of the real DB table for some reason. Which is rare.

One (not very strong) reason to avoid LIKE is that it creates a dependency on a DB connection which in turn may allow unwanted DB references to creep into your code. This mostly relevant to .W's. If your .W"s run thru AppServer, it makes sense to NOT have a DB connection when you compile them, because you won't when you run them. If you use LIKE, you have to have that connection. This same concept could, I suppose, be applied to other multi-database situations.

 

[Mike Derrick]

My 2 cents: Whether or not it's best practice, we use "Define LIKE" all the time. Our app is designed to run either Single User, Client/Server or with the Appserver. A few years back, we opted to go with an ADM2 front end to simplify the UI development, and to do that, we define our client side TTs with LIKE in the SDO's so they look like the database tables that are being updated. (There are a few exceptions of course.) And, as you well know, in order to utilize the Appserver, the UI must NOT have any database connections at runtime. It's a simple thing to ferret out any unwanted DB runtime connections with an XREF compile.

When a schema change is made, a recompile takes care of any CRC issues, and of course, we developers responsible for said schema changes, are also responsible for any code that may be affected. By using LIKE for the TT definitions, it saves loads of otherwise unnecessary maintenance of TT fields and indexes when a schema change is made. So I would have to agree with Cringer that "a temp table like the db table is almost imperative" is our case.

My short answer is, we use LIKE all the time.

 

[GregTomkins]

My short answer is, we use LIKE all the time.

Fair enough, I guess you and Cringer use apps where what the user sees is a relatively direct representation of what's in the DB tables and/or you are OK with business logic in the UI. Both of which are I am sure fine for many situations, but not ours.

 

[RealHeavyDude]

Just my 2 cents:

Using a data access layer to abstract the form in which the data is used in the business logic and possibly in a UI, IMHO does make sense and really adds value. But in reality I see that many applications that get developed today, although they are not directly accessing a database, are still tied to the database and changing the database schema has side effects all over the place in the application. I also should state that reality, IMHO of course, neither is black nor white, most of the times seems some variant of gray to me. Using the LIKE option as provided by the Progress ABL might not be best practice, but nevertheless it might solve gray problems in a particular environment.

Personally I don't like the usage of LIKE when defining temp-tables because it will tie the application to a specific database.

Working in a very heterogeneous environment where different applications play different roles in a business transaction and sometimes even regulatory compliance or external auditors require mastering some type of information in a different data room (which almost always is an application talking a different technology) it is invaluable to me having a clean separation of business logic and data access layer. That does not mean that I don't have to change the application when the environment the application is running in changes, but I have a clearly defined place where I need make the changes - the rest of the application is not affected at all and it makes my test engineer's life so much easier. Don't need to rewrite all the regression test cases.

But it appears to me that the requirements for the applications I need to develop are not the same requirements for applications that other developers are responsible for. Plus I know that people responsible for budgets will certainly accept every shortcut taken in order save costs now. Seldom have I seen these people care about the mid to long term future. The only bad thing is, that applications which are developed as strategic interim solutions years ago are still running today and it becomes harder by the month to adapt them to new business needs and the business people don't understand when you tell them that your design can't cope with their new requirements anymore because of design flaws. They expect you to have your job done right in the first place ...

Heavy Regards, RealHeavyDude.