Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Transaction Processing

Status
Not open for further replies.

GoodOldRob

Programmer
Sep 10, 2003
8
0
0
GB
Does any one use the transaction processing in FoxDOS(2.5) if so what do you think of it ?

Note:
-----
I am running several multi user apps on a Novell (5.?) network and regularly get errors like
- Not a database file
- Index does not match database

I was thinking that transaction processing might solve my problems.


 
There isn't really any transaction processing with Foxpro 2.5, unless you mean the Novell TTS stuff.
But don't expect it to cure the ills you mentioned.
We (at various companies I have worked for), have attempted to fine tune TTS for some of those veru reasons. It never really did the job.
What you first neen to do is eliminate the possibility of hardware failures such as bad NICs, wires, hubs, etc.
Then, polish the network client - make sure you have the latest, and set caching to a minimum.
Finally, the most common problem of all, is users rebooting their computer in the middle of a transaction.
Ideally, you need to optimize code and put up plenty of messages to let the user know that the computer isn't just locked up.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
While it can be a 'pain' to change everything over, to minimize the "users rebooting their computer in the middle of a transaction" problem, you might want to consider setting up all edit screens so that they work on memory variables and/or temporary tables rather than directly on "live" table field contents.

Then when the user has completed their operation they click on the SAVE or COMMIT button and the 'live' table(s) are opened, temporary data is transfered as needed, and then the 'live' table(s) are closed.

In this manner if users shut down their system in mid-operation, there is less likelihood that REAL system tables and its data will be compromised.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
 
A few standards would still minimise the risks of corruption.

In the beginning of the code.
SET EXCLUSIVE OFF
SET MULTLOCKS ON

Before every "fetch".
SET NOTIFY ON
SET REPROCESS TO 5 & or SET REPROCESS TO AUTOMATIC
DO WHILE !LOCK()
Fetch / "Select - sql" command
LOCK()
ENDDO
SET NOTIFY OFF
IF !LOCK()
do your rollback rutines / messages
RETURN (most probably)
ENDIF

The only unusual thing above is the "SET NOTIFY ON". This is necessary since the timeout system error gets trapped before your application ON ERROR routine and if NOTIFY is off, the message (system message in this case) doesn't get displayed, the user thinks the system is hanging, resets .. you know, the works to corrupt the data base.

And after the insert / update / delete,
UNLOCK()

In addition, the usual things for optimising the environment for multi user (CONFIG.FP containing TMPFIELS, SORTWORK etc) reduce unecessary network traffic and have an direct positive result on the performance and corruption issue.

End

 
Back in '95 I started to do an AR system using the Novell TTS stuff. After inquiring with some other knowledgable engineers I came to the conclusion that it wasen't worth it and it certainly does not solve everything.

Recall the famous axiom:

You can't make a system foolproof because fools are so ingenious!

NullOp
 
To quote someone.

The Programmer's job is to create better and better foolproof programs.

The Universe's job is to create better and better fools.

Score so far.

Universe Several Billions of Billions, Programmers Zero.

:-0



 
Dear NullOp:

Your quote is very amusing.

GoodOldRob: So what do you do to fix the problem, when not a database file message displayed ... ?

NasibKalsi
 
As a short-term solution, you can use one of the DBF repair programs (i.e. FixFOX, FixDBF, etc.) to attempt to fix the database.
A more long-term solution is to re-work the code to minimize the problem of users corrupting the databases in one of the ways suggested above.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top