I dont understand where the problem may be

4GLNewbie

Member
I am posting here because i really dont know where can be the problem in this situation. So i dont know where it would be correct to open this thread.

I try to explain.

1. The situation.
Users log in an application server where the main application is. Every login creates a new windows session so they can use the application.
Main database ( oracle ) is on another server.
The program has a main window and here you can run all program features using menues, user interfaces, buttons etc etc.

2. Description of the problem.
Sometimes, seems randomly and it has not been found a situation that is equal to the other, it happens that:
you click on a button that must open a program reading data from db;
then the program seems to be reading data and it s all frozen, blocked and you cant do anything;
the widgets of the program and the main window are not loaded but you cannot do anything because ( it is correct that happens, in a normal situation ) everything is disabled to let the new feature run and appear;
users go crazy because they cannot go on working.

3. More info.
I can say that:
- if i enter the application using the same program user but creating my own new server (windows) session: i do the same thing and this program opens correctly!
- you can wait as long as you want but the "blocked" one does not ever recover ( ever waiting an hour )
- looking at the db, i can see no table locks ( in fact i can open the same data using another user ), and the program access table only to read data
- sometimes i kill some random db sessions that seem to be remained open incorrectly and then the programs comes back to life, as summoned by a wizard ( the user of magic of fantasy stories )
- it does not happen everytime, i have not been able to determine a defined condition that causes the problem to raise
- the table that is used from the program has a lot of records and even using tools like Toad it takes a lot of time to be displayed

4. What do you think about that?
I accept every clue you would give.
Do you think that may be a problem related to the application?
May be that it is a problem related to db instead? A session blocked, problems in accessing data, conflicts of other kind?
Network issues? I dont think so but i cant exclude anything.

5. Does anyone know a way to try to discover the problem cause?
If there is a tool that can monitorize the db sessions, ie, to let me know if that session has problems, it s blocked, there is a connection problem and so on, let me know.
May be it is a problem on the application server? How can i discover it?
Other ideas?

Many thanks in advance. I know i ask you a lot.
 

HPM75

New Member
Have you checked the application server logs for clues?
Have you checked the database log for clues?
Can you write temporary logging output in the program that runs so you can determine how far it gets before it hangs?
 

4GLNewbie

Member
In the server logs ( Events Registry ) i cannot find nothing useful. It does not occur an error i must say.
I am not the db manager, but i think activate logs can cause to run out of disk space in very short time..

Many that have more experience than i ( have ) have tried to figure it out. Db side and application side.

The reason i dont undestand is why at the same moment i can access the same data with another windows session user and i can see the program load without problems.
And the random occurrence of the trouble makes it very difficult to track ..

Thanks for your reply anyway.
 

TomBascom

Curmudgeon
This is a Progress 4GL application running against an Oracle database?

The client platform is apparently some version of Windows?

What is the server platform?

What versions of each product are being used?
 

4GLNewbie

Member
Yes, that is. Progress that runs over an oracle db.

In fact the user do something like a remote desktop login on the server. But there is no problem about logging in and using the application server with the clients for what i know now. I dont know of issues related to to log-in method to enter into the application server, the client used has the same version of the server-side remote login service ( only for i.e., assume that i m using Windows Remote Desktop ).

Server runs a Windows Server 2003 edition.

Progress version under the procedure editor is 9.1D09
Db version is Oracle9i Release 9.2.0.5.0

I already answer to your possible question, Tom, and i say that i cant do an update of the two, progress or oracle.

Thanks in advance for your replies.
 

TomBascom

Curmudgeon
Server runs a Windows Server 2003 edition.

Progress version under the procedure editor is 9.1D09
Db version is Oracle9i Release 9.2.0.5.0

I already answer to your possible question, Tom, and i say that i cant do an update of the two, progress or oracle.

Why not? It's the obvious thing to do.

You ought to upgrade Windows too.

If you insist on staying with v9 your options boil down to adding a lot of logging to your startup process so that you can reliably determine where and why you are hanging. But you seem reluctant to add logging.

If you upgrade you could leverage more modern capabilities like the new debugger or -clientlog, -logginglevel and -logentrytypes and so forth.
 

4GLNewbie

Member
I m not the man to tell that. I do not take that kind of decisions. I try only to understand why it happens, that's the goal to reach.

So i am focusing on understanding where is the problem. Sorry man, but "upgrade" is an answer that dont helps me a lot.

^^ thanks anyway for reading this issue.
 

4GLNewbie

Member
This goes a little OT, but there are situations in our life where we dont have the chance to take decisions. We just have to do what we can with what we have.
I ve not told you that i dont wanna to, i told you that i dont take that kind of decisions: but still you did not gave me an explicit reason to upgrade in relation to my issue.
If you think that it is the best solution for every problem, okei i accept your opinion. But let me disagree with you.

I m happy that you dont have that kind of problem in your life. But it is not my situation.

Thanks again for your replies.
 

TomBascom

Curmudgeon
You may not be the person who makes the ultimate decision but you surely have the ability to open your mouth and suggest that course of action.

You are right, I do not have a specific identifiable reason why upgrading will fix your problem. In large part because you have not actually descried an indentifiable problem.

You have also indicated that you do not want to help yourself by adding logging to better trace the problem.

You are, however, using a release of Progress that is 6 or 8 years old. Obviously there have been a lot of bug fixes and improvements in the time since. It does not seem unreasonable to me that an upgrade might very well solve your unknown problem.

Upgrading also might not magically solve your problem but at least you would be in a supportable position with significantly improved diagnostic tools. If, for instance, you were to upgrade to OE10.1C (or better) you would be able to obtain a client stack trace from a "hung" session. That might be pretty darned useful. You could also be using the new attachable debugger to trace program flow. And there are lots of other very useful features available that would be invaluable in tracking down such problems.

So just exactly is it that you're hoping to achieve by posting? Are you looking for the magic -zFixMyProblemThatICannotActuallyDescribe startup parameter?
 

4GLNewbie

Member
Tom, i just posted to see if someone else ever had the same problem and then fixed it.
A forum is made for this, i suppose. But if you dont think you have any other idea rather than suggesting me to upgrade, i dont understand why you are going on to reply in this thread.
You think that i dont want to help myself and all other things you said above: okei, i can understand your position and maybe also agree with you in the general meaning of what you told me..
But please, dont make us continue with this.
It is unuseful to you, because if i tell you that i cant that means that i can not, not that i dont would like to.. And also for me, because this does not help me out anyway to find even an undefined idea.

Thanks for your suggestion Enoon. Will check that.
 

TomBascom

Curmudgeon
I disagree.

Progress version 9 was released 10 years ago and it is no longer supported in any realistic manner.

I may sound like a broken record on the issue but people posting to this and other forums and people dredging up old threads deserve to know that upgrading is by far and away the most practical solution to a very large number of problems.

Especially problems that are vague and poorly defined and even more especially for issue of inter-operability.
 

4GLNewbie

Member
You clearly specified it more than two times only considering this thread.
Am i wrong? Go on repeating the concept till the end of time, if you want. That s the way to use a forum indeed.

Good day then. Nothing personal, let me tell you.
 

TomBascom

Curmudgeon
Ditto on the "nothing personal". I'll happily repeat it until the end of time so long as people try to deny that it is useful and possible.

I happen to think that it is a very good use of the forum. There are clearly a great many people here who need to hear it and understand it.
 

Casper

ProgressTalk.com Moderator
Staff member
Re: I dont understand where the problem may be (OT remark)

The whole point is that there is never a good reason not to upgrade. One of the major benifits of Progress is that you can upgrade to any version of Progress without worrying to make changes to the code. It happens that the compiler is more strict in some cases, but that is also good because that only happens in situations where you coded something not right.
The 'can't' upgrade has most times to do with the vendor not willing to maintain more then 1 version of the product or the customer of the vendor not willing to upgrade to the latest version of the product.
If for instance people ask question about problems they have with there windows 95 pc that it is more then likely that people say that instead of trying to fix the problems you have with windows95 it is better to use a more up-to-date version of windows like Vista or at least XP.

BTW, try asking Tom about find first :awink:

Talking about versions, I think your Oracle needs an upgrade too ;-)

Unfortunately (or fortunately) I never worked with dataserver and I am afraid I can't help you. Did you try to drop your question at TS? The description seems clear enough to me for them to work with.
Try making a 4GL trace file, then you might be able to find the culprit.
Would be nice if you where able to reproduce it, because then it is easy to debug and see what goes wrong.


Regards,

Casper.
 

tamhas

ProgressTalk.com Sponsor
I don't know about anyone else, but I've completely lost track of what this thread was about. You might want to try creating a fresh thread in which your initial post summarizes all of the actions you have taken based on the suggestions here and explaining why you haven't taken other actions that were suggested.

And, while you are at it, instead of being negative and defensive about the upgrade issue, recognize that upgrading is a good thing, that it might simply eliminate the problem, that it is likely to give you better tools for diagnosing the problem, and then say that you can't do it right now because other people have to get convinced before it is possible, but that you will look into it since you know it is the right thing to do.
 

jdgibson

New Member
Looking at the original problem you described I would suspect this is a locking issue even though you say you can see no locks. For sysmptons where killing a session reactivates the progam it is hard to think of anything else. It is however likely to be not the data you are viewing in the program but some other record related to the user. To test this run the program for one user and open the screen causing the problem. Then login as the same user on another PC and try to open the same screen. If you get the behaiviour you are describing on the second PC it is possibly the locking of a user related record.
 

4GLNewbie

Member
I will not talk anymore about things that have been already told.
Good reasons and things that is better to do dont mean that things will be done that way. If this is not your world, i m happy for you people, it's mine.

And i will not open any other thread, because the answers will be the same given before and then will become a duplicate of this one.

Talking again about the issue itself.

- i have excluded locks on the db: differents users can view the same data while another seems blocked

- i think it is not related to windows or remote desktop version; the issue should have been triggered also for other sizes of the applicatione, without regards of what table/view the software was accessing

- sessions dont explain the trouble completely , because one goes on while another it is frozen

In my opinion the problem is related to table-size.

In a table that has a great number of records, maybe the program freezes because it accesses a great number of them.
So i cant imagine the developer that, when doing some tests while creating the procedure, did not notice a poor performance and let the things as it were.

I did some test with an analogue problem on the same table ( it appeared only yesterday ), and excluding the part that access the same tables of this issue, the application does not seem to have problems.

So i think this issue is related with db size.

Thanks again for the help to anyone that gived me a clue.

Regards
 
In my opinion the problem is related to table-size.

In a table that has a great number of records, maybe the program freezes because it accesses a great number of them.
So i cant imagine the developer that, when doing some tests while creating the procedure, did not notice a poor performance and let the things as it were.

I did some test with an analogue problem on the same table ( it appeared only yesterday ), and excluding the part that access the same tables of this issue, the application does not seem to have problems.

So i think this issue is related with db size.

Quite feasible, and although you may not be able to imagine a developer missing it, in my experience programmers have been known to not test things thoroughly.

Just to clarify your issue (as you call yourself a 4GLNewbie), if the problem is as you describe it (and obviously you need to verify that by testing suspect queries on the suspect table(s) directly), then it is more likely not down to table (or db) size, but poor database design, and in particular a lack of proper indexing.
 
Top