darkowl72 said:My bad. You're absolutely right. 👍
Look, since we started out talking about just three workstations, nobody mentioned thousands of entries being logged every single day. Based on what I've seen and dealt with over countless years, I immediately pictured a small office with three desks, a machine, filing cabinets overflowing with folders, and maybe three clerks processing 200-500 orders daily for about fifteen different clients. If I'm wrong and we're actually dealing with double those amounts, it's still not enough volume or revenue to justify a serious server and a "real" database capable of handling thousands of daily queries.
I agree on the backup situation too. That’s why I suggested two mirrored drives, and an additional backup—just like we discussed in that other thread—can be automated to a USB drive.
In setups like this, you usually have one terminal serving a single client's database, but even if all three 😬 hit it at once, it's still well within the capabilities of a DBF file. Honestly, a huge chunk of accounting services still run through a Command Prompt using applications built on generations of Oracle and Visual Basic, while the rest use modified legacy apps adapted for some tiny, free SQL solution.
I know the era of DBF solutions is long gone and plenty of firms implemented proper SQL solutions ages ago, but given the state of our economy, it’s honestly amazing that any service can even think about buying new gear instead of struggling on machines where an IBM port is the only way to connect a printer. 😬
Bottom line is, I jumped the gun here and rushed into things without asking the right questions. It's a perfect example of how years of experience can actually work against you, and just proof that you never stop learning.
Nah, you didn't mess up at all. Maybe I just know my way around this field a little better than most? You know how it goes.
Look, logic says one thing—business processes, resources, all that stuff—it all looks like it’s on your side. But reality? Reality is a whole different beast. That's why I always tell people to start with the software house first. Get them to lay out the bare minimum, or even the ideal, system requirements right out of the gate. Why? Because the second a problem pops up, you're going to get stuck in this endless game of ping-pong between the hardware guys and the software devs. And guess who always ends up taking the blame? It’s always the other guy.
So, I was looking at some recommended hardware setups for a local medical clinic recently. They’re looking at a two-computer setup—one "server" and one "client"—that basically just runs everything through a browser and a tiny local database for patient records. They have to stay connected to the Social Security Administration systems, too. Get this: they’re asking for an i5 and an i3 combo, and they’re actually recommending Windows 7??? Seriously? Right when everyone is scrambling to transition away from Windows XP because support is ending, they’re suggesting an OS that’s literally next in line to be retired. Makes any sense to you?
Wait, hold up. When we first started talking about this, we were only mentioning three workstations. Nobody mentioned thousands of orders being logged every single day! Based on everything I've seen and dealt with over the years, my brain immediately pictured a single room with three desks, a couple of computers, and filing cabinets overflowing with paperwork. I'm picturing maybe three office assistants cranking out 200 to 500 orders a day for about fifteen different clients. If I've miscalculated and we're actually talking about double those numbers, that's still a pretty small workload. Is that really enough revenue to justify dropping serious cash on a heavy-duty server and a "real" database capable of handling thousands of queries every single day?
You nailed the visualization there, but I know for a fact that for the same workload, people were also pitching SQL Server running on its own dedicated Windows server. It’s just a setup where you have a file server and then clients hitting the data through desktop apps. Simple enough, right?
I'm totally on board with the backup idea. That’s exactly why I suggested running two disks in a mirror. Plus, we can just set up an automated routine to dump an extra backup onto a USB drive—just like we were talking about in that other thread. Easy, right?
In setups like that, you usually see just one terminal handling a single client's database. But hey, isn't it always fun when all three decide to crash at the exact same time? 😬 It’s the same old story when it comes to that DBF domain. Honestly, a huge chunk of accounting services out there are still running on legacy MS-DOS apps built back in the day with Visual Basic and Oracle. Then you've got the other half just scraping by using old-school DOS setups that were patched together with some tiny, free SQL Server Express solution. Isn't it wild how much of this stuff is still hanging on?
So, why is that even the case? 🤷I'm not exactly an expert on SQL, but I'm guessing this was their way of making concurrency easier to manage. If they didn't go this route, they’d probably be dealing with constant table-level locking issues. Or maybe row-level locking just makes their business logic, referential integrity, or relations a total nightmare? Who knows how they actually put this whole thing together... Bob knows.
You’re pretty much spot on. Some of these solutions are functionally "polished" straight from the old Visual Basic days, then ported over to modern platforms using Borland or something similar. Honestly? That’s more than enough to get the job done. At the end of the day, the real headache here is the lack of synergy between the devs and the actual industry experts. Once you finally get that connection dialed in, it’s a massive pain to break it apart just to start building everything from scratch again, isn't it?
Some old-school apps were practically perfected back in the MS-DOS days using procedural programming. They squeezed every ounce of efficiency out of keyboard shortcuts—because let’s be honest, using a mouse for repetitive tasks just slows you down. When you port those solutions today, they keep that killer ergonomics but get a massive boost from object-oriented coding and multi-window support.
For databases, any solid desktop solution works fine. Whether it's Firebird or SQL Server Express, the main thing is that it's way more stable and secure than an old DBF file. You want something where a crash doesn't wipe out the whole database, maybe just losing the last record you entered...
I know the era of DBF solutions is long gone, and plenty of service providers moved to real SQL solutions ages ago. But given how our economy works, it's honestly amazing that there are still businesses capable of even thinking about upgrading their gear instead of being stuck on machines where an IBM port is the only way to connect a printer.😬
The problem is that users don't really care or even want to change. They're constantly being pushed by shifting regulations, fake certificates, total digitalization, exporting data into specific formats, and automating reports—you can't do all that without some kind of GUI report generator...
Even though the core principles of the job haven't changed in hundreds of years, the tools are getting insanely complex. To get the same result, you need beefier hardware, and time is becoming more precious and expensive... I mean, you could probably build almost everything in Excel, but users would mess it up so badly within a day that the whole system would collapse...
Look, the bottom line is that I messed up here. I rushed into things without asking the right questions, which just goes to show how years of experience can actually become a blind spot sometimes. It's a classic case of "you live and you learn." :top
Experience is built on common sense, and that's exactly what you followed. The government, however, seems to think "change is the only constant," so you're never fast enough, and you can never stay sane.
Everything points to the fact that any modern PC should run this without a hitch. I take that with a grain of salt, though; I prefer my computer to be reasonably fast and still have some life left in it, rather than being at its absolute limit from day one and struggling later.
Anyway, I always stick to the rule of "read the manual and ask the pro," especially when it comes to work. Since these kinds of questions get asked here on the forum, your response is totally fair and expected. A serious professional should talk to their vendor first—especially if they aren't looking for a "turnkey" solution—because they're the ones who have to live with the software. Trying to save money on business operations by following random advice from a forum? That's just asking for trouble...
