Dos Error 59 : any experience?
Marco Boschi
with "xHarbour Compiler build 1.2.1 (SimpLex) (Rev. 6634)"
Is a couple of days I have this problem
Error DBFCDX/1011 Write error: n:\hse\manut.dbf Arguments: ()
(DOS Error 59)
( this problem has happened only twice: once a day )
It seems strange because this is a program running on a server and n:
is a server volume
Dos error 59 is "Unexpected network error"
Any ideas
marco
dlzc
When in the code does this happen... at startup, or add / change?
The server process, what rights does it have to write to this volume?
What Windoze software is running on the server?
David A. Smith
Marco Boschi
It's a software that read information such as dbf table name, record
number and transfer these changes to other servers.
It is a program that works for many years.
in dbcommit() in log table dbf crashes.
> The server process, what rights does it have to write to this volume?
I would say the usual: update, read, delete
> What Windoze software is running on the server?
WIndows Server 2003 R2
Service Pack 2
>
> David A. Smith
Enrico Maria Giordano
"Marco Boschi" <in...@marcoboschi.it> ha scritto nel messaggio
news:0cafdb5d-0b9b-41a0...@o14g2000yqe.googlegroups.com...
> during execution. This is a software that run in batch mode.
> It's a software that read information such as dbf table name, record
> number and transfer these changes to other servers.
> It is a program that works for many years.
> in dbcommit() in log table dbf crashes.
A faulty network card?
EMG
--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic
dlzc
On Jan 11, 10:22 am, "Enrico Maria Giordano"
<e.m.giord...@emagsoftware.it> wrote:
> "Marco Boschi" <i...@marcoboschi.it> ha scritto nel messaggionews:0cafdb5d-0b9b-41a0...@o14g2000yqe.googlegroups.com...
>
> > during execution. This is a software that run in batch
> > mode. It's a software that read information such as
> > dbf table name, record number and transfer these
> > changes to other servers. It is a program that works
> > for many years. in dbcommit() in log table dbf crashes.
>
> A faulty network card?
Code-performance and data reside on the same machine. Micro$haft
talks about various sorts of intermittent faults like this, and its
sounds like the "dining philospher's" problem.
I would wonder if having the code map to the resource by the more
network friendly method "\\server_name\path_name\file_name", might not
eliminate the issue, or at least generate a more useful error message.
Marco, can you show us the wasy you connect to the source tables, and
the destination tables? Please feel free to "munge" the names to not
reveal secret information...
David A. Smith
Enrico Maria Giordano
"dlzc" <dl...@cox.net> ha scritto nel messaggio
news:beff283e-d015-4634...@s9g2000vby.googlegroups.com...
> > A faulty network card?
>
> Code-performance and data reside on the same machine.
???
dlzc
On Jan 11, 1:50 pm, "Enrico Maria Giordano"
<e.m.giord...@emagsoftware.it> wrote:
> "dlzc" <dl...@cox.net> ha scritto nel messaggionews:beff283e-d015-4634...@s9g2000vby.googlegroups.com...
>
> > > A faulty network card?
>
> > Code-performance and data reside on the same
> > machine.
>
> ???
I should have said "code-execution", not "code-performance".
"It seems strange because this is a program running on a server and n:
is a server volume."
Ostensibly, no network traffic is generated through the network card
to be corrupted. The executor of the program *is* the server that has
the data.
Depending on how he asks for resources...
David A. Smith
Enrico Maria Giordano
> I should have said "code-execution", not "code-performance".
>
> "It seems strange because this is a program running on a server and n:
> is a server volume."
>
> Ostensibly, no network traffic is generated through the network card
> to be corrupted. The executor of the program *is* the server that has
> the data.
Marco, can you confirm this? I don't think so, as the error clearly reports
"Unexpected network error".
Marco Boschi
<e.m.giord...@emagsoftware.it> wrote:
>
> A faulty network card?
In my opinion NO because the table is on a server volume
Marco Boschi
> the destination tables? Please feel free to "munge" the names to not
> reveal secret information...
>
> David A. Smith
C:\WINDOWS\system32>net use
Le nuove connessioni saranno memorizzate.
Stato Locale Remota Rete
-------------------------------------------------------------------------------
OK N: \\dbserver\apps Rete di Microsoft
Windows >>> THIS IS A LOCAL VOLUME
OK O: \\dbserver\dati Rete di Microsoft
Windows
OK P: \\mailserver\c$\www Rete di Microsoft
Windows
OK R: \\nashp\sft Rete di Microsoft
Windows
OK S: \\mailserver\APPS Rete di Microsoft
Windows
OK T: \\mailserver\David Rete di Microsoft
Windows
Esecuzione comando riuscita.
SELECT manut >> manut.dbf is a table in n: (local volume)
DBCOMMIT() >>> At this point I Have 59 error
DBRUNLOCK()
ENDIF // reclock()
You mean this?
Ella-Ilona Stern
In Clipper and other xBase languages it has no importance where are
sitting the free DBF and index files, the table manipulation commands
always bring some table rows in the local station's memory.
In case of having customers working in various environments ( hardware
or software ) all the data manipulation commands ( append, replace,
delete etc. ) should be placed inside separate functions, and those
functions repeated a number of times before giving up. Example:
- slow networks: 10-20 retry with pauses of 0.5...1 seconds
- fast networks: 20-50 retry with pauses of 0.2-0.5 seconds
Ella
On Jan 12, 11:16 am, Marco Boschi <i...@marcoboschi.it> wrote:
> > Marco, can you show us the wasy you connect to the source tables, and
> > the destination tables? Please feel free to "munge" the names to not
> > reveal secret information...
>
> > David A. Smith
>
> C:\WINDOWS\system32>net use
> Le nuove connessioni saranno memorizzate.
>
> Stato Locale Remota Rete
>
> -------------------------------------------------------------------------------
dlzc
On Jan 12, 2:16 am, Marco Boschi <i...@marcoboschi.it> wrote:
> > Marco, can you show us the [way] you connect
> > to the source tables, and the destination tables?
> > Please feel free to "munge" the names to not
> > reveal secret information...
>
> C:\WINDOWS\system32>net use
> Le nuove connessioni saranno memorizzate.
>
> Stato Locale Remota Rete
>
> -------------------------------------------------------------------------------
> OK N: \\dbserver\apps Rete di Microsoft
> Windows >>> THIS IS A LOCAL VOLUME
> OK O: \\dbserver\dati Rete di Microsoft
> Windows
...
>
> SELECT manut >> manut.dbf is a table in
> n: (local volume)
> DBCOMMIT() >>> At this point I Have 59 error
I also wanted to know if this happened on the first record, or some
record further on.
> DBRUNLOCK()
> ENDIF // reclock()
> You mean this?
Yes. Please correct what I say next, if required.
- \\dbserver is the computer that is running the application.
- the data files being accessed are in the root of \\dbserver\apps, or
a subdirectory of that.
- the server application gets the error 59, not your connected-by-
wires-or-wifi users.
I suspect the drive mapping is still performed by one of the the
network card's interface layers, even though the data never travels
over the network wiring. That is why you might get an error 59,
executing a program on the data on the same machine.
Micro$haft does not like constantly-accessed data to reside in
applications directories, in general. I worry about the permissions
your *application* has to this directory, whether it is run as
"Administrator", or the "user" that it is... has full permissions to
that mapping. Might have to check with the guy that set up your
network (if it was not you).
Things you might try:
1) move the data files to the "O:" mapping (or yet a new mapping if
data security is required).
2) see if you have better luck with the physical drive mapping, rather
than network mapping, although this may be bad practice.
As to things that might have changed that would produce this error
"suddenly":
- updates from M$
- changes by your network guy to the network / permissions
- changes to physical hardware / drivers
Good luck, Marco.
David A. Smith
Marco Boschi
many thanks
marco
Marco Boschi
> - \\dbserver is the computer that is running the application.
> - the data files being accessed are in the root of \\dbserver\apps, or a subdirectory of that.
In a subdirectory
> - the server application gets the error 59, not your connected-by- wires-or-wifi users.
The server, Yes
> I suspect the drive mapping is still performed by one of the the
> network card's interface layers, even though the data never travels
> over the network wiring. That is why you might get an error 59,
> executing a program on the data on the same machine.
ok
> Micro$haft does not like constantly-accessed data to reside in
> applications directories, in general. I worry about the permissions
> your *application* has to this directory, whether it is run as
> "Administrator", or the "user" that it is... has full permissions to
> that mapping. Might have to check with the guy that set up your
> network (if it was not you).
ok
> Things you might try:
> 1) move the data files to the "O:" mapping (or yet a new mapping if data security is required).
yes
> 2) see if you have better luck with the physical drive mapping, rather than network mapping, although this may be bad practice.
ok
> As to things that might have changed that would produce this error "suddenly":
> - updates from M$
> - changes by your network guy to the network / permissions
> - changes to physical hardware / drivers
>
> Good luck, Marco.
Many thanks David