Member Avatar for benyam_dessu

I am write a payroll grogram. Is it possible to make this program run in the network? I mean, how could I make it for users at different workstations access it simaltaniously.

regards,

ben.

  • 2 Contributors
  • 3 Replies
  • 124 Views
  • 15 Hours Discussion Span
  • Latest Post Latest Post by Comatose

Dani AI

Generated

As suggested, there are two broad approaches behind the short answers already posted: 1) place the data file on a shared network drive so every workstation reads/writes the same file, or 2) create a client/server arrangement (sockets or a DB server) so clients talk to a central process that controls all access. Both work, but they differ sharply in reliability, concurrency, and maintenance.

Shared-file approach (fastest to implement): put the data file (Access MDB/ACCDB or a flat file) on a server share and map it on each workstation. For Access, split the database into a back-end (tables) on the server and front-end (forms/code) on each PC; give users read/write permissions to the backend folder. Expect limits: record locking, .ldb/.laccdb lock files, greater chance of corruption under network glitches, and poor scaling beyond a few simultaneous users. Regular Compact & Repair, disciplined backups, and minimizing large binary fields help, but this remains fragile for production payroll.

Server-based approach (recommended for payroll): host the data in a proper database server (SQL Server Express, MySQL, PostgreSQL). Benefits include true transactions, row-level locking, better concurrency, security controls, scheduled backups, and easier scaling. Migration steps: move tables to the server, change the app to use a server connection string or DSN, use parameterized queries and transactions, and keep the UI/front-end on each client (or centralize the UI as a web app). This is the safest route for sensitive payroll data.

Socket/client-server approach: implement a dedicated server process (Winsock/.NET sockets or, more simply, a web service) that enforces business rules and serializes access. This gives full control over concurrency and keeps business logic server-side, but requires more development and testing. Checklist for any approach: enforce proper permissions, implement transactions or optimistic locking, schedule backups, test with expected user counts, and treat payroll data as sensitive—use encryption and strong access controls where appropriate.

Relevant mentions: gave the two core options; needs to choose between quick shared-file setup (short-term) and a server-based design (recommended long-term for payroll).

Recommended Answers

All 3 Replies

Member Avatar for Comatose

Sockets.... or a file on a shared drive.

Member Avatar for benyam_dessu

Sockets.... or a file on a shared drive.

I didn't get Ur idea. would U mind to explain more?

regards,

ben.

Member Avatar for Comatose

Well, in windows you can make a network drive.... which is like, a folder on computer A, is actually a drive on computer B. So when you open up the networked drive, you are actually opening up the folder on the other computer.... so you store the file on the networked drive, and you map the drive for all the workstations, and make the program access the file which is stored on the networked drive.

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.