We use a Marvell Yukon 88E 8050 PCI-E ASF Gigabit Ethernet Controller. It did made a sustancial improvement, no only on DBA/EVO but overall.
 
Of course if you get the best ethernet controller but you have a slow RAID controller it will not make much diferent. Get a new server  
 
 
 
Kelloggs
 
PD: We have 35 Evo Users, and around 100 computers on our network.

Quote from GasGiant on 05/16/07 at 09:41:25:

 
It is understandable that running Evo locally on the DB server would make some reports go faster. The reason is that the old btrieve interface fetches records one per call instead of the usual SQL all at once or in batches approach. Even over 1Gb/s ethernet you will still have some network latency. Your network latency is less over local connections than it could ever be remotely. Remember, even a 1/2 a millisecond counts. If it has to wait for each packet transmit (which it more or less does in TCP) then .5ms a call means only 2000 calls a second. Since in btrieve one call = 1 record you then can only transmit 2000 records per second (at best) if your round trip is .5MS. For reference, at home my average ping time to my local router (100Mb/s) is 3.7ms over wireless. Rounding that to 4ms would give me 250 record exchanges a second between my machine and the router (assuming that it hypothetically was running PSQL)

Quote from GasGiant on 05/17/07 at 07:22:55:

 
Yes, it is counterintuitive in a way. The many thousand calls to the DB server are costly but it's not certain to be more costly than the processing time. It depends on the server's load. If you are heavily loading your server (which you shouldn't do) then offloading report processing to the workstations would speed things up. But if your DB server is powerful enough then it would be best to run the report right there where the data is and just send the result back.  
 
This is, of course, basically exactly what I've been saying all along. It's not really any different than how I've been saying that btrieve is an old, dead technology and that SQL is the way forward. A SQL query *WOULD* run on the DB server and *WOULD* report back just the results. The resulting returned data then must just be properly formatted and displayed. The whole shooting match could be done in very few network transmissions. As badly as DBA screwed up in outsourcing their new version to some startup in New Zealand they still did the right thing. It didn't work out (as anyone who has seen DBA-NG can attest to!) but they at least tried. More normalization, better database product (and free too!) and SQL based. It's really the way to design a database app. 'Twas a bit too much to bite off all at once though... It's a shame...
 
Of course, Pervasive SQL quite obviously supports SQL too so there's nothing on the database side that prevents something like EVO from doing more server side processing. Except, of course, for my arch nemesis TAS7.
 
Which, leads to the same conclusion we've been at for a while: We need to get together and replace the existing Evo reports with Crystal reports or something. CR can do SQL queries and so can PSQL so the combination could be used to offload some work to the DB server.

Thanks for the info.
 
That really validates my point that Evo's biggest problem isn't the programmers or the people using it it's TAS/BTRIEVE. Both are pretty well worthless in my opinion. Give me php, sql, C#, and VB any day. The fact that your PHP/SQL apps are way faster than TAS/Btrieve should tell ISTech all they really need to know.... Not that I expect them to port the whole thing to PHP any time soon, though that'd be SWWWWWWEEEEEET! Talk about true client/server architecture! That would obsolete any need for a terminal server. I've thought about trying it on one of the EVO apps. I don't know which... Maybe IN-A or something. It'd be neat to have a web based version but well time is ever in short supply. That and so is source code.