Member Avatar for sandyk007

I had some doubts running clipper programs in Linux. I am having dos based clipper programs for accounting which we are thinking to migrate to Novell but i am for Linux ,considering cost and may in future Linux cost effectiveness may help us, plus security and scalability.

Actual Scenario:

Small office network10/100Mbps (6-8 clients), where we use Clipper-based program for accounting. First, we thought of an old NetWare as a server and Diskless Netware Clients, then I suggested it with linux+Samba. Now i have abouts of corruption of database in Linux and whether dos emulators might work if they work will they really slow around with 6-7 clients connected . Is it possible to speed it up somehow (with new hardware?) or may be native speed of dos emu s can be overcome by some way.

  • 4 Contributors
  • 3 Replies
  • 298 Views
  • 11 Months Discussion Span
  • Latest Post Latest Post by JoetjeF

Dani AI

Generated

Summary and practical steps for the thread: described DB corruption when running DOS/Clipper accounting software over a Samba share; asked for specifics and reported similar interest; suggested recompiling the sources. The core point missing from earlier posts is that file-based xBase/DBF applications are fragile when multiple DOS clients access the same files via a network share — the problem is almost always locking/caching, not raw network speed or CPU.

Quick, non-destructive triage (work on copies/backups only):

  • Run the app against a local copy of the database on one machine. If corruption disappears, the network is implicated.
  • Check Samba locking behavior and server logs (smbd, syslog) and use tools like smbstatus to see locks.
  • Try a Samba share with explicit locking settings to disable client caching. Example smb.conf snippet:
    [clipper]
 path = /srv/clipper
 read only = no
 locking = yes
 strict locking = yes
 oplocks = no
 level2 oplocks = no
 share modes = yes

    Those settings reduce opportunistic caching that breaks DBF-style apps; they can slow throughput slightly but remove corruption.

About emulators and alternatives: DOSBox is single-user and not suitable for multi-client DB sharing; DOSEMU/Wine can run binaries but do not fix file-lock semantics. Hardware (faster disks, gigabit switches) improves throughput but will not prevent locking-induced corruption. If source code exists, porting to a native Clipper-compatible compiler (or to Harbour and a client-server SQL backend) is the clean long-term fix. If sources are unavailable, the safest short-term approach is a single dedicated host that runs the app locally and gives other users remote sessions (RDP/VNC), or keep a Windows/DOS server that the clients access via terminal sessions rather than file-level sharing.

Always keep frequent backups and validate them after any migration or Samba tuning; data safety must be the top priority.

Recommended Answers

All 3 Replies

Member Avatar for oberoc

Sandy, can you be a little more specific?

-Tino

Member Avatar for eror

I know exactly what you're talking about. I'm trying to do the same thing. Will ms dos emulation solve the problem, or some linux tool is needed?

Member Avatar for JoetjeF

Probably a bit late, but if you still have the sources then you can recompile them using Clip .

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.