Re: VB6 Winsock action on Server

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"jerry_ys" <jerryys@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:E0340CB3-4FCE-4536-B621-B3405FFE3B67@xxxxxxxxxxxxxxxx

Let me clarify a bit more. While VB is not my forte it at
least appeared after some scrutiny to contain the technology
for reasonably clean client/server apps only using features of
the product and not having to fudge and patch critical areas.
The more we discuss, with due respect, it seems this is not
the case.
How are you coming to this conclusion?
My recommendation, to use ADO for your solution, is caused
by the fact, that VB and its Controls were designed with ADO
in mind.
All of VBs enhanced RAD-features shine a bit brighter in
combination with ADO, building DataAccess-Applications
with very few lines of code.
For example - you can visualize the Content of an ADO-
Recordset inside a VB-Datagrid (and open it for edit) with
only one single line of code:
Set Datagrid.Datasource = Rs

The system is for a non-profit club, which I having knowledge
in the main frame environment volunteered to put together for
it's members.
Clearly the route of using VB and a medium price range server
without too much OS goodies seemed like a doable solution.
(yes home grown, reinventing the wheel, etc., whatever is
indeed the case here)
Please, don't bother with the term "homegrown" - I just tried to
make clear, that there are tools out there, that come with the
OS (ADO) or are free to download (DB-Servers), wich can
shorten your development-time significantly.
The "homegrown" alternative (Winsock-Arrays + implementing
locking/transaction mechanisms yourself (wich allow secure and
concurrent file-access of multiple clients), needs much more effort
until you reach the point, where you visualize your first Data-
Record inside a VB-GUI.
That doesn't mean, that the additional effort for such a solution
couldn't be worthwhile, because there are scenarios, there you
expect more than the usual data-transfers and transactions, wich
actual DB-Servers already have to offer.
What do you expect from your own implementation besides the
data-access?

I do not understand why the Winsock control and basic access
methods that I describe , which by the way are the same
rudimentary building blocks used for any non- home grown
DBMS) in Windows and basic access methods that I describe,
would have a problem handling 100 clients.
There is no problem with this approach - but you will have a much
greater effort, to handle the concurrent access to your large file.

Also, unless I totally misunderstood you, your free program that
I obtained through the link provided in your first response to my
question, appears based on timing estimates to be able to very
easily accomplish this task. (did I miss that there was a DBMS
supporting anything here?)
Our RPC-Server (from the link you've mentioned) is of course able, to
handle thousands of COM-Calls per second (requests against Public
Classes inside ActiveX-Dlls) from multiple Clients in parallel, but it was
not built, to replace a DBMS "out of the box". Its main-purpose is, to
act as an additional layer *before* the DBMS, retrieving disconnected
Recordsets from a DB-Server using ADO inside the RPCs and do
additional processing at the server-side, before returning the results
back to the client.
If you want to use our solution, then you can skip the implementation
of your own server (based on Winsock-Arrays) and you can also skip
the development of your own WorkerThread-Pool, wich should be
able, to handle incoming requests in parallel.
But what is left, is the IMO huge effort, to implement a proper, and
transactional safe handling of multiple Read/Write-Requests against
the Records sitting inside a huge FlatFile.
And this effort is (let me say it again) IMO not sustainable, as long as
there are no good reasons, to do so.

As already said in my last posting - let me know, what those reasons
are.

Olaf


.

Relevant Pages

  • Re: Tiger Stock
    ... supports a portable DBMS. ... So you're saying that while you were passionately promoting these now ... Can you provide specific reasons for them to avoid ... clients to make are very different from those which Martin asks his ...
    (comp.databases.pick)
  • Re: Client Wants Design Access To Database
    ... prospective database so that they can change reports if and when ... I have always distributed my projects as mde files for obvious reasons. ... This request is new to me and I am interested if other developers have ... I've never been burned by this and generally my clients hire me to make ...
    (comp.databases.ms-access)
  • Re: What is the official social status of musicians?
    ... Was this statement accurate: "You can ... tell any individual that it's possible to get a good life but the ... Matt there are good reasons to borrow and not good reasons. ...  I have had four or five clients that went from being refugees to ...
    (rec.music.classical.guitar)
  • Re: Deny MX queries for dynamic IP pools
    ... solution for many reasons such as clients that have email servers ... those are exactly the reasons why some ISPs block port 25 access. ... clients to find out correct site in case of mistake. ...
    (comp.protocols.dns.bind)
  • Please recommend DBMS for upcoming project
    ... neither a web design guru nor a dbms guru. ... i understand that "best is relative blah blah" and that there is no ... which will change from week to week and month to month, and clients ...
    (comp.lang.tcl)