Hello,

I am running Baan IVc3 and attempting to customise the session Print Receipt Log via a simple report script. The change I am adding is simply a date range and I am using the lattr.print variable in the script to supress the printing of records not included in the date range.

I have found a way of supressing my before field by using a simple sql statement on tdpsc007 to check for the receipts against the supplier. However since I've added this statement the detail lines on the report have began to misbehave. It's as if somehow with the select statement I'm moving the record pointer on the main tdpsc007 table.

So what I'm really looking for is a way to return to the previous record on the table before my SQL statement. Is there a 4GL statement which will preserve the position of the record pointer and then allow me to return to it after my sql.

Regards

Neal Matthews
Intier Automotive - IT Support Analyst

Maybe in the report script you can just use an alias of the table. Since your just using lattr.print this should stop the problem. The select in the script is probably filling in report variables that still need to be printed in the detail layouts.

Mark

There is no connection between the SQL record pointers in the report session (4GL) and the report script (3GL).

It looks like you might be overlaying report fields with your report script date range SQL statement. Try returning a field that doesn't exist in your report, something like:


|example sql only
select tdpur045.date
from tdpur045
where tdpur045._index1 = {:tdpsc007.xxxx, ...}
and tdpur045.date between xxx and zzz
as set with 1 rows
selectdo
lattr.print = true
selectempty
lattr.print = false
endselect

if its still giving u error, you can as well use alias. Its better to be on the safer side always.

Thanks for your replies.

How would I use an alias ?

Neal Matthews
Intier Automotive - IT Support Analyst

Like this:

select tdpur045_a.date
from tdpur045 tdpur045_a
where tdpur045_a._index1 = {:tdpsc007.xxxx, ...}
and tdpur045_a.date between xxx and zzz
as set with 1 rows
selectdo
lattr.print = true
selectempty
lattr.print = false
endselect

Mark

Thanks for that chaps.

In the end I had to look at table tdpur045 as I was still having problems even when using an alias. The only drawback with using this table is the fact that we archive tdpur045 but we should get away with it.

Regards
Neal

You could always create a based variable to hold the record for the table (e.g., rcd.ttdsls045) and then restore it after your processing. This has worked well for me in the past. I have also had problems getting aliases to work for me consistently.

Hi Ed,

Excuse my ignorance but how would this work exactly ?

Cheers
Neal

Basically you store the value of the current record, do your processing, and then restore the record to its previous value. Baan uses this in some of their scripts (e.g., tdsls4404).

First, you declare a based variable to hold the record. Then you allocate memory to the variable. After that, you do the assignment. When you are done, you free the memory. For example,

string buf.tdsls045 based
long row.length
...
db.row.length(ttdsls045,row.length)
alloc.mem(buf.tdsls045, row.length)
...
buf.tdsls045 = rcd.ttdsls045
(do processing)
rcd.ttdsls045 = buf.tdsls045
...
free(buf.tdsls045)
You could also save the table keys and do another select. The record method avoids another database hit.

Thanks Ed,

That seems to work pretty well.

The only problem I've got is with freeing the memory as the compiler spits out the free() function as not being recognised. Is this a function you've put together yourself or is it a standard function I'm missing ?

Regards
Neal

If you search for free in the online help you will see that the function is called free.mem and not free.

(At least in 5.0)

Han

Thanks Han,

The compiler is now happy.

Regards
Neal

Sorry. My mind was working faster than my keys. the free.mem command is definitely what you want to use on 4 or 5.

Wow! :D :D :D :D :D :D :D

I was looking for something like this because my detail lines were messing a lot.
I tryied using aliases, and altought the compiler didn't return any error, when I ran the session it said: SELECT VARIABLE 'alias_name' (type 2) not defined
I don't know but I think the use of aliases in a report program cannot be used :confused: (think this because I use aliases in my program scripts and they work)

I did it as evesely said so, and it works perfectly, thanks a lot!!!

Now, if somebody can tell why BaaN returns that error in a report script :p
BaaN IV c4

Regards

Not sure what you mean - I use aliases in report scripts.

declaration:
| 20051004.st
table ttirou001 | Work Centers
extern domain tchrs.amnt req.resources
extern domain tcnoru main.resources | 20051004.end
header.1:
| 20051004.st
before.layout:
select a.noru:main.resources
from tirou001 a
where a._index1 = {:tirou001.mnwc}
as set with 1 rows
selectdo
endselect | 20051004.end

Not sure what you mean - I use aliases in report scripts.

declaration:
| 20051004.st
table ttirou001 | Work Centers
extern domain tchrs.amnt req.resources
extern domain tcnoru main.resources | 20051004.end
header.1:
| 20051004.st
before.layout:
select a.noru:main.resources
from tirou001 a
where a._index1 = {:tirou001.mnwc}
as set with 1 rows
selectdo
endselect | 20051004.end



If I put that code into one of my reports the compiler doesn't return any error, but when i run the report, in the BW Message windows it inmediatly says undefined symbol "a" SELECT VARIABLE 'alias_name' (type 2) not defined and it doesn't work

Any Idea??

Thanks

Can you post the query? I just ran this report today. We are on SP20 4c4 - it might be a patch is just needed.

Can you post the query? I just ran this report today. We are on SP20 4c4 - it might be a patch is just needed.

Thanks Mark, this is the query:

before.inco.10:
before.layout:
select t41.*,t45.*
from tdsls041 t41, tdsls045 t45
where t41._index1 = {:worea}
and t41._index1 refers to t45
and t45.ssls > 5
selectdo
i = i + 1
selectempty
endselect

Everything goes well when compiling, no errors, but when this query runs it return that messages.

The curious thing is that this same query in a program script runs perfectly:confused: , no errors in the compiler nor executing it!!

Thanks in advance...

_____
Alex

Is there is more to the query than you posted? If not, I would use:

select count(t41.orno):i
from tdsls041 t41, tdsls045 t45
where t41._index1 = {:worea}
and t41._index1 refers to t45
and t45.ssls > 5
selectdo
endselect

If there is more to the query I would try using at least some field names instead of the "*". I know it works in the session script and I think it should also work in the report script. Is there more to the query?