Re: VB6 Winsock action on Server
- From: jerry_ys <jerryys@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 4 Jun 2006 14:02:02 -0700
How are you coming to this conclusion?
With the introduction on your part of ADO and DBMS. I thought that ADO is
largely
to be used to connect and manage data flow between client and DB? I think you
are suggesting to utilize (even with your software) the usage of ADO and a
DB on the server? Also the usage and positioning of the word PHEW on your
part. Sorry
if I jumped the gun.
My recommendation, to use ADO for your solution, is caused
by the fact, that VB and its Controls were designed with ADO
in mind.
And in conjunction with a DB
I think the issue is namely how to control concurrent access. DBMS vs
Homegrown.
Personally as see it as simple as using an active x exe server (which based
on all documentation I have seen states that it runs only one copy, as
multiple client winsock controls attach to it. Additionally if this exec is
specified as single thread, the control and data file sysnchronization falls
under control of the exe. Simple DB
yet effective and able to do the job. Why I initially wrote my post is to
gain additional knowledge on the feasibility of adding threads for more
efficiency with
this basic approach. Am I completely off base?
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.
I have great interest in the above approach, but from my experience when using
free software, one typically encounters more problems and requires very
specialized
knowledge to resolve. This is principally why I'm deferring that solution.
But, I may
be wrong.
What do you expect from your own implementation besides the
data-access?
Other than the control issues we have been discussing the implementation is
all that I could expect when viewed only from a one client perspective. VB has
done a wonderful job. As mentioned previously the issues of cost and a full
time
administrator for the database, ease of maintaining and changing
requirements, etc
are all better without a DBMS. Typically, lets assume a DBMS has 100 specific
functions, then most implementations will utilize only 5 of those functions
on average. Also I have found at least on main frame IBM DB2 for example is
unrealistic for client ad-hoc reporting requests due to significant resource
use.
In any case I want a system that does not use more resources then it needs, at
least those under my control.
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.
While it is true that many transactions in the real world have multiple I/O's
especially to multiple tables to complete and that does involve greater
complexity,
my system minimizes the the I/O for any one request.
As already said in my last posting - let me know, what those reasonsI think I did. If not please let me know.
are.
I now conclude that everything that I want to do is very possible (even
without DBMS) but would require much more effort.
Please comment on my points in this reply.
Thanks
Jerry
.
- Follow-Ups:
- Re: VB6 Winsock action on Server
- From: Schmidt
- Re: VB6 Winsock action on Server
- References:
- Re: VB6 Winsock action on Server
- From: jerry_ys
- Re: VB6 Winsock action on Server
- From: Schmidt
- Re: VB6 Winsock action on Server
- From: jerry_ys
- Re: VB6 Winsock action on Server
- From: Schmidt
- Re: VB6 Winsock action on Server
- Prev by Date: Re: ActiveX.exe more problems
- Next by Date: Re: OOP Question
- Previous by thread: Re: VB6 Winsock action on Server
- Next by thread: Re: VB6 Winsock action on Server
- Index(es):
Relevant Pages
|