lg-file/ Progress 9.1C / Windows 98

Hello,
I have a question to the ld-file of then Database in Progress.
Normally progress writes information in this file(s) of each database at the start an at the end of Progress (<name>.lg).
But I have a now a client respectively a PC where Progress doesn't write any lg-file since severel weeks. Has anyone an Idea?
How can I solve this Problem?
Matthias Röttgermann
 
The database log file will be in the database directory -

Is the database local to the PC, or is the user connecting across a network?

If the latter, is the client connecting with user id you expect?

Is the user perhaps showing up as blank?

Is the client connecting Read-Only? Prior to 9.1D, the connection will not be logged.

Is the client connecting through SQL? The user needs to be in the user list for user name to show in some versions.

Make sure the connection parameters are as you expect (are any pf files being picked up?).

If these are all ok, I'm perplexed - it is my understanding that connections are always logged in the dbname.lg file.

Lee
 
I guess what I would do is:

Stop the Progress client (disconnect).

Take a snap shot of the end of the dbname.lg file. Look at it in (say) notepad, not progress explorer.
Reconnect the progress client, ensuring you are not in read-only mode.
Take another snapshot.

If there is no new login information, contact Progress Tech support to clarify why this might be.
 
Is the database local to the PC
=> yes
, or is the user connecting across a network?
=> no

If the latter, is the client connecting with user id you expect?
=> no
Is the user perhaps showing up as blank?
=> no
Is the client connecting Read-Only? Prior to 9.1D, the connection will not be logged.
=> no
Is the client connecting through SQL? The user needs to be in the user list for user name to show in some versions.
=> no
Make sure the connection parameters are as you expect (are any pf files being picked up?).
=> the´pf-file when Progress starts:
-stream iso8859-1
-p bin/sysstart.r
-E
-d dmy
-T c:\temp
-s 63
-nb 160
-trig c:\refos9\kasse\bin\db_trigg
-lng ?
-yy 1990
-mmax 4096
-wy

If these are all ok, I'm perplexed - it is my understanding that connections are always logged in the dbname.lg file.

Greetings
Matthias Röttgermann

Lee[/quote]
 

ddavis

New Member
There is the possibility that the log file has become disconnected from the running progress process.

Not sure of the terminology here, but if you do something with the log file that might change the inode, or the pointer to the file from the pointer the process in memory has (like opening with vi and then using wq to exit, or any other process that would write over the current log file), then the running process might continue to write to the pointer to a non existent log file while your log file sits there dormant.

This could only be the case if there was no activity in the log file whatsoever.

Restarting the db server will fix this.

Hope that helps.
 
Hello and thanks,
I think this might be the problem.
No I have solved it: I deleted the lg-file and with an new start of the server Progress writes correctly to the lg-file!.

Matthias

There is the possibility that the log file has become disconnected from the running progress process.

Not sure of the terminology here, but if you do something with the log file that might change the inode, or the pointer to the file from the pointer the process in memory has (like opening with vi and then using wq to exit, or any other process that would write over the current log file), then the running process might continue to write to the pointer to a non existent log file while your log file sits there dormant.

This could only be the case if there was no activity in the log file whatsoever.

Restarting the db server will fix this.

Hope that helps.[/quote]
 
[Cross post]


Wouldn't a 2257 error be posted in this situation?

(Unable to open or create dbname.lg)

I wonder if there also any permissions problems or antivirus activity that might interfere.

I would also suggest restarting the server, but I assumed he would have tried that (if there are not many users).

Any related messages in the Windows Event Viewer?
 
Good catch dd.

A quick way of checking this next time may be to use a OS process lock checker like Unlocker to see if log file is being held by mprosrv.

This would allow you to check without stopping the server. Of course, this would not be a foolproof method.

Lee
 
Lee Curzon said:
[Cross post]


Wouldn't a 2257 error be posted in this situation?

(Unable to open or create dbname.lg)
=> no

I wonder if there also any permissions problems or antivirus activity that might interfere.
=> I don't think so, but I didn't test it.

I would also suggest restarting the server, but I assumed he would have tried that (if there are not many users).
=> yes: only one server and max 5 Clients

Any related messages in the Windows Event Viewer?
=> I don't know where I can find this; I think it's not activated.

Thank you very much for your help and your ideas!
Matthias
 
Sorry (again) Matthias,

It is not available in 98.

Later versions: Control Panel > Administrative Tools > Event Viewer.

Lee
 
Top