Re: Roll your own VB6 server...
- From: "Bob Riemersma" <sorry@xxxxxxxxxx>
- Date: Sun, 31 Aug 2008 12:08:11 -0400
I'm not sure why you'd go to this trouble either.
For the needs you've briefly described you can probably use SQL Server Express... or even a Jet database or two as your datastore. Most of the problems people have with Jet stability are related to client machine and network failures, which won't be such an issue when Jet itself runs on the same box housing the MDB.
Creating a home brew DMBS with decent recoverability and a broad feature set is not a weekend task.
As far as a "connector" technology, you could do far worse than a little thing Microsoft introduced before Web Services were everywhere: Remote Data Services (RDS) which is part of MDAC/DAC. Don't confuse it with the "other" RDS (Remote Desktop Sharing).
RDS got a bad rap because as originally released it wasn't very locked down, and worse yet it shipped with samples that had painfully stupid vulnerabilities. Most people installed and forgot the samples, opening up a huge hole in their servers. The product was later sandboxed to prevent the most glaring problems and the samples were disabled (though you can still re-enable them to run). Shortly after the .Net juggernaut was underway and many people forgot about RDS.
Like VB6, RDS is "deprecated." However it still ships as part of Vista, and I'll bet it is even in Windows Server 2008.
RDS lets you "remote" your ADO connections over DCOM or HTTP/HTTPS. For the most part clients just use ADO as they always have, though you can optimize them by moving to the disconnected model explicitly... just as one does with a Web Services scenario. Note that using Jet as your DBMS, the engine itself only runs at the server and not in each client. Even SQL Server connections don't extend out of the server under RDS. RDS operates by serializing requests and Recordsets and sending them to and fro, all without a bunch of explicit code in your VB6 applications (ADO handles it for you via a Remoting Provider).
It is vastly easier to use than the SOAP Toolkits were.
RDS also supports custom server "business objects" (and COM+ pooling if needed for scalability) so it isn't limited to just ADO data access. You might have to scrounge for a decent book on the topic today though.
However your best "hardware" option might be to deploy to a dedicated virtual server at some commercial hosting provider. Don't underestimate the hidden costs and headaches of hosting on your own.
"Schmidt" <sss@xxxxxxxxx> wrote in message news:unprXS2CJHA.4932@xxxxxxxxxxxxxxxxxxxxxxx
"Nigel V Thomas" <nospaml@xxxxxxxxxx> schrieb im Newsbeitrag
news:32B3DC76-6E1D-41AC-952A-96769E6F36E9@xxxxxxxxxxxxxxxx
I have an application which is ideally client server based.Unless your planned Application is real simple, I'd recommend
My target audience is price point sensitive which prohibits
Windows Server software and associated hardware/support.
Available resources are:
Fixed IP address based router
ADSL broadband connection (low and shared bandwidth)
Vista/XP based low end PC's
VB6 experience
Max connections 20
I was thinking of writing my own VB6 based Winsock based
server with a B-Tree index based Random Access database.
not to write all this stuff yourself.
In fact all of your requirements are already encapsulated
for VB6-usage in my toolset, which is public domain.
It includes a DCOM-like ApplicationServer and a BTree-
based, singlefile DBEngine is also encapsulated in an
ADO-like way (based on the great SQLite-engine from
sqlite.org - newest version 3.6.1).
And 20 concurrent clients is nothing for that engine,
with 8 concurrent clients I reach up to 10000 requests
per second on a cheap 2GHz AMD-DualCore.
Although I know this is possibleAs said, the toolset is freeware - and it works reliable and
could someone please enlighten me on any possible pitfalls - am I
going in the right direction in order to keep cost down.
with very good performance also on Linux/Wine.
So you can build your own server with very low
investments.
E.g. the Asrock AliveNF7G-HDReady is a great board
including Graphics and Gigabit-Network in its chipset,
fully supported by modern Linux-Distributions like e.g.
the new versions of Ubuntu or Sidux (both Debian-based).
Put 2x1GByte-Ram on it and a cheap DualCore AMD-
CPU (the LE-types are recommended for low power),
add a (maybe 2.5") harddisk and you are basically done.
This setup runs fine here (together with an highly efficient
PicoPSU-power-supply) drawing only ca. 22W of power
from the wall (ca. 50W under full load), so you can also
keep your energy-costs low, since such a server typically
runs 24/7.
Security?You probably want to use it over internet, so the AppServer
has builtin compression and strong encryption (Public-Key
Diffie/Hellman-based, to prevent Man-in-the-middle attacks).
The toolset is downloadable here:
www.datenhaus.de/Downloads/dhRichClientDemo.zip
Unpack the zip to e.g. c:\RichClient\
First you should try the already compiled Apps from
its Bin-Folder (start the server-part = RPCServer.exe,
and then the client-part = RPCDBDemoClient.exe)
and play around with it. This should work out-of-the
box.
Then, if you want to take a look at the Demo-Sources,
you will have to place a copy of only the two Standard-Dlls
(DirectCOM.dll and sqlite35_engine.dll) additionally in
\Windows\System32, but that's only needed on your Dev-
machine, to let the Demo-Projects work within your
VB6-IDE.
Here's another link, which will give you an easy start,
on how to use the RPC-Tools (with clientside round-
trip-debugging, if you start the appropriate *.vbg-
Projectgroup, which includes the ClientApp (VB-
Std-Exe) and the Server-Project (AX-Dll).
www.datenhaus.de/Downloads/SimpleRPCDemo.zip
Olaf
.
- Prev by Date: Re: How to check for this file path?
- Next by Date: Re: Intellisense
- Previous by thread: Re: How to check for this file path?
- Next by thread: Re: Intellisense
- Index(es):
Relevant Pages
|
