Use FIND with a variable

[ezequiel]

Hello,I need to know if is it possible to use something like this:

def var cTable as character.
cTable = "customer".
find first cTable.

...so I can use same code to find any table. I use 9.1C

Is there a way to do this?

Thanks

 

[Cringer]

Yes - use a dynamic query.

 

[ezequiel]

Thank you, Cringer.

I was trying to avoid a dynamic query. But if there is not another way, I'll do that.

I usually include OS and Progress Version, this time I didn't post the OS. I thaugt it was no relevant. I'll include it next time.

Thanks again!

 

[Cringer]

That's just my signature In your case the other two were irrelevant, but it's worth posting them all the same. That way there's no delays.

Out of intersst why were you avoiding dynamic queries? Is there a specific aspect you were having trouble with?

This code might help...

define variable lv-Query as handle no-undo.  
define variable lv-QueryString as character no-undo.  
define variable lv-BufferName as character no-undo. 
define variable lv-TableName as character no-undo.  
define variable lv-BufferHandle as handle no-undo.   

for each _file no-lock   where _file._hidden = false:      
  lv-QueryString = "FOR EACH " + _file._file-name + " NO-LOCK".   
  lv-BufferName = _file._file-name.   lv-TableName = _file._file-name.   
  create buffer lv-BufferHandle for table lv-TableName buffer-name lv-BufferName.       
  create query lv-Query.   lv-Query:add-buffer(lv-BufferHandle).   
  lv-Query:query-prepare(lv-QueryString).   
  lv-Query:query-open.      
  lv-Query:get-first.      
  message lv-Query:query-off-end view-as alert-box.       
  lv-Query:query-close.   
  delete object lv-Query. 
end.

 

[RealHeavyDude]

I don't see any point in avoiding dynamic queries. IMHO they really rock!

To me it boils down to a similar discussion regarding the use of reflection in Java. Me, having my roots in the ABL, I can't understand why one should not use reflection.

Heavy Regards, RealHeavyDude.

 

[Stefan]

I was trying to avoid a dynamic query. But if there is not another way, I'll do that.

You do not need to go completely dynamic. You only need a dynamic buffer object:

DEF VAR ctable AS CHAR INIT "customer".
DEF VAR hb AS HANDLE.

CREATE BUFFER hb FOR ctable.
hb:FIND-FIRST( "", NO-LOCK ).

DELETE OBJECT hb.

If you want a FIND instead of FIND FIRST then you can use the FIND-UNIQUE method.

 

[olala]

You can use .i file with code:
FOR EACH {&table} :
Display {&table}.{&filename}.
END.
then call .i and pass the table name to .i Example: olala.i &table = "customer".

 

[tamhas]

Normally, .i means include file and those references are resolved at compile time, not dynamically at run time. It is possible to write a .p file with ABL code and then run it, but that requires an appropriate licenses which many clients may not have.

 

[ezequiel]

I'll try dynamic tomorrow at work. I'll let you know.

 

[GregTomkins]

I don't see any point in avoiding dynamic queries.

How about, much more verbose, and therefore subject to errors that won't generally be caught until run-time?

I used to be a big dynamic everything fan, but these days, my feeling is that static is usually better except for clear cases where it's not, eg., general-purpose utility type stuff.

If you went 100% dynamic, I think you would basically be discarding all the strengths of P4GL ... at that point, you may as well jump back into the mainstream and use Java.

 

[RealHeavyDude]

I am using the dynamic stuff since it came around with Progress V9 - which is, I think, for some 14 years now. I have to admit that I really had an excellent mentor at that time who was really good a explaining things and that I had to find out some things the hard way. And, you are right, one size does not fit all - meaning, there is good reason for doing things the static way and there are good reasons for doing things the dynamic way.

But I feel urged to say that using static code does not mean that you do not need to thoroughly test. There are things that the compiler will complain about, but that does not mean that your code works as you meant it to. For me that is no argument to avoid dynamic stuff.

I don't want to fight religious battles, I just found out that there is no reason to avoid something, but that does not mean that you have to use it just for it's sake.

I would never use a dynamic query for batch processing a table that contains billions of rows. But I do use dynamic stuff for generic logic in many places of applications where it allows me to build re-usable, robust business logic components.

Having said that, I am not saying Java is better than the ABL - or vice versa. I am just saying that both are tools which have their strengths and weaknesses. Plus, both tools offer features which might be appropriate to get a job done but are not necessarily best practice for every job. Basically, I do love the ABL - but I do love Java too. In fact, I am really in a fortunate position to use both of theses technologies working together without a fuzz in a huge project - using each of the technologies for what they are good at. Plus, I do not use reflection just for it's sake - I use it when I need it to get the job done.

 

[ezequiel]

I haven't tried dynamic yet, there is a lot of other more-urgent stuff to do.. more urgent, less pleasant

BTW, Really Heavy Dude, your signature about Klingon is great!