Hello All,
I having a very basic question.
I´m filling a table with records that have a specific characteristic.
Before to start the fill, I clear the table, in order to select the "fresh" records. Then I make a report using that table.

My question is. What will happen if two or more users runs the sesion?
I mean, due to I make a clear table instruction, and start to fill the table with fresh records, If a second user, runs that session, the clear table instruction, will work?

I know when I do a clear table, the user obtan a exclusive lock on that table until the first session finish. Is it correct?

Or, what can I do to prevent that an accidentaly, record delete (or insert) before the report finish?


thank you in advance!

Not the best, but what I typically do is include user-name and pid. This way I did not have to worry about locking the table, plus the user could have multiple sessions open and running. On sessions where it makes a difference and only one version should be running I use application locks so nobody else can even run the session.

I agree with Mark's suggestion, but why "not the best"? I applied such logic (i.e. field username and utc-time or pid) plenty of times on my temp-tables, and it works perfectly... Can you explain why you are not so happy with such a system?

Can you explain why you are not so happy with such a system?
No problem - I think there is probably some easier method that I do not know and nobody has posted it yet. :) Usually for me these tables are not true temporary tables, but permanent tables that only get used on occasion. I also have never looked at doing true temp tables - more coding.

I think it would it be cool if you could create small tables local to the program. Then you could search it, report it, etc, when the session is closed the memory is released. Something kind of like I used to do in the "wayback" days of when I was programming in C(mark williams C on digital computers back in the 80's).

Thank you Mark & En,
As allways, your inputs are good.

Any have an example for doing what I suppose to do?
I mean, on my first report aproach, I put the sentence clear table. Then I started to fill with records.

So, what I have to implement in order to just clear some specific records, and take that to do a report?

Thank you in advance.

Hi Mig28mx ,
This is good question. In past I had to make report like your case. When I do this, main aim is to provide report to user. Among the running report this sepecial session should be used by only this user. That's why table lock or MArks suggestion are good solution but another alternative way is using application lock.

In Program Script side.

string username(12)

choice.cont.process:
before.choice:

if appl.set("lock.name",APPL.EXCL) <> 0 then
appl.get.user("lock.name",username)
message("Session is locked by %s",username)
else
appl.set("lock.name",APPL.EXCL)
execute(print.data)
endif

choice.print.data:
on.choice:
if rprt_open() then
read.data.and.send.them.to.report()
appl.delete("lock.name")
rprt_close()
else
choice.again()
endif


This is basic way.

Another way is to use timestamp. You should add timestamp field your table. In your program

string timestamp(12)

timestamp= dte$()
insert.data.to.table.with.timestamp()
send.data.to.report.with.concerned.timestamp()
delete.data.with.timestamp(timestamp)


That'S all. There is a minimal bug in this logic. If users run it in the same timestamp (MMDDYYHHMMSS). Error occurs. But this is vey very small possibility. Sometimes some events can be omited according to usage of report.

Good LUCK !

This is not such a small probability when you are running a big site with many hundreds or maybe even thousands of users. A simple solutions for playing safe is using a combination of 3 unique identifyers: username, timestamp & sequence nr. Like this you're covered even when for instance 2 different people use a same login name (happens in nearly every organization...)

I must say though, that I do not normally use temp-tables for reports, since you can sort and filter your print output any way you want it without having to use temp tables. I normally use it when I'm forced to do very complexed sorting and filtering on display sessions... Then it is easier, faster and safer to stuff all the selected and sorted data into a temp table first and then display the records from the temp table in the session, but for reports.....???

Regards,
Eli Nager

I said that Sometimes some events can be omited according to usage of report.
It depends on your structure. I know what you mean enfrom, But this is choice and this suggestion can be improved.
I belive that there is no best one forever, the best one is not best forever. My suggestion is not best one but the best one is not also best. I hope you got it !

Good Luck !

Sample of the table. I use this in a session script where I build the tables different ways depending on what is on the form. By adding seqn as Eli suggested would certainly get a unique index value. Good luck!

And believe it or not I understood "My suggestion is not best one but the best one is not also best". The requestor will need to decide which is best in their situation.

This is not such a small probability when you are running a big site with many hundreds or maybe even thousands of users. A simple solutions for playing safe is using a combination of 3 unique identifyers: username, timestamp & sequence nr. Like this you're covered even when for instance 2 different people use a same login name (happens in nearly every organization...)

I must say though, that I do not normally use temp-tables for reports, since you can sort and filter your print output any way you want it without having to use temp tables. I normally use it when I'm forced to do very complexed sorting and filtering on display sessions... Then it is easier, faster and safer to stuff all the selected and sorted data into a temp table first and then display the records from the temp table in the session, but for reports.....???

Regards,
Eli Nager

Hello Eli,

i agree with you to use temp-tables only for complex sorting.
But this sorted temp-table can also be used for reports. I've done this for
a very complex sales statistic based on tdsls051, which can not be done by the BaaN standard sales statistic.
The data in this table is built with an always unique index by the session logic and then used for the report. And after the report is printed, all the data for this PID is truncated.

Regards

Hello all,
I want to thank to everybody for your invaluable inputs.
Specially for mr_suleyman.
His suggestion work like a charm!

Bye.