ASTA? WebHub? dbOvernet?
Darcie & Molly
was wondering if ASTA, WebHub and dbOvernet are similar products. If not,
what are the differences? In terms of flexibility, scalability and speed
which product is superior?
Thanks,
James
Marc Scheuner
Not really.
ASTA and dbOvernet are basically the same - in theory, in what they
try to achieve. They strive to make it possible for you to have your
client program (a Delphi program) anywhere out there in the world,
accessing a database located somewhere else, through the internet, at
a decent speed.
So basically it's breaking up the Delphi app into a thin client
program and a smart / fat server, both written in Delphi,
communicating over the internet.
Based on what I know and hear, I'd strongly favour ASTA for this task.
WebHub on the other hand is a different beast all together. It's a Web
application package, again, written in Delphi. The main difference
here is: you write applications / modules that runs as part of a web
server (or rather: an extension thereof), so you're always tied to a
web server, you're always dealing with web browsers as the clients.
This has its advantages (you don't need to write any client - you just
create the web pages that get sent back to the client browser),
however, it also has drawbacks (try creating web pages with decent
menus, toolbars etc. - browsers are just not as powerful as a Win32
GUI app).
Marc
---------------------------------------------------
Marc Scheuner
Software Engineer
FastLane Technologies Inc.
Email: mailto:msch...@fastlane.com
Voice: (902) 432-8160 x2213
Plan, Deploy, Manage Windows 2000 with FastLane DM/Suite.
Optimize Windows 2000 now!
http://www.fastlane.com
Mike Kolter (Customizable Components)
very hard to make sure that there are plenty of third party options
available to ASTA users. Steve and I are working closely to build a bridge
between our two products so that building scheduling applications that run
over the 'net will be a relatively easy thing to do. I'm not sure of other
products, but I believe that ASTA already does support most of the popular
db engines. There has also been talk of one or more accounting solutions as
well. You'd have to ask Steve about the details though.
Mike Kolter
President, Customizable Components
http://www.cust-comp.com
"Marc Scheuner" <msch...@no.spam.for.me.ca> wrote in message
news:mjitgsgsheirqnj3v...@4ax.com...
Kelvin Taite
task.
>
Please explain in detail.
What advantages does ASTA have over dbOvernet?
What makes you "strongly" favour ASTA? I know this is your opinion
only but I am curious as to what specifically you have come across
that would sway you towards ASTA.
Before you reply I'd like to let you know that I have been using
dbOvernet for about a year now with extremely good results. When I
evaluated the two options (ASTA and dbOvernet) I selected dbOvernet
due to the way I could access, beyond the normal attribute settings,
the information I received or sent. Although I have not been
following ASTA development closely, I have found dbOvernet to be
maturing nicely.
Regards
Kelvin Taite
Special Projects, Provincial Airlines Ltd.
kta...@provair.com
Derek Davidson
I hope that you don't mind me piggy backing your message here, but I'd
like to respond to your question.
I've been using Asta for some while now. I came across it when I
realized I couldn't code what I needed through Web Hub and force it
into a web browser. I gave up after three months (long, hard) effort
and looked at Asta instead. Three weeks later my app was complete with
WAY more functionality and (with the good offices of ASPack) a simple
client deliverable at only 650Kb. Stunning stuff.
But why Asta instead of dbOvernet? Personalities & legalities. I
liked Steve Garland and Ernie Ezis (the co-founders of Asta Technology
Group). They clearly loved what they did and were VERY responsive to
developer needs. They still are. Only today, Steve EMailed me a new
Asta server that promises more speed for use with the app I'm
producing. You'll always see Steve here on the newsgroups and is very
accessible. That kind of support is priceless.
As far as Fred Dalgleish and dbOvernet went, all I saw was legal
posturing on who owned what technology and the tenuous relationship
between dbOvernet and Francois Piettes TCP/IP technology/components (of
which I find no mention currently on the dbOvernet web site). I rarely
see Fred on the newsgroups (only once in the last year on Feb 15, 2000)
for the topics that I read. I must applaud Fred though for his
marketing and the speed with which he brings things to market (though I
cannot ratify the stability of the software).
FWIW
Derek Davidson
Loren Scott [Vista Software]
If you are just looking to connect to data through the Internet, the Apollo
Database Server includes this capability as a standard feature. This does
not require IIS or Personal Web Server running on the server PC, nor does it
require the Enterprise Edition of Delphi -- the Professional Edition of
Delphi works just fine.
Please visit www.ApolloDatabase.com for additional information on Apollo VCL
and Apollo Database Server.
Best regards,
Loren Scott
President/CEO
Vista Software - A Vision That Works!
http://www.ApolloDatabase.com
1-800-653-2949
Gordon Hamm
Asta is also less expensive at $400.00.
--
Gordon Hamm
Voice Data Systems Inc.
360-686-8315
Loren Scott [Vista Software] <lor...@vistasoftware.com> wrote in message
news:8en79g$14...@bornews.borland.com...
Loren Scott [Vista Software]
>> Asta is also less expensive at $400.00. <<
Thanks for the extra info. I was not aware of Asta's price. From what you
are saying, you'd need to buy a database engine and then also pay $400 for
Asta to make it work over the Internet.
Apollo Database Server _includes_ the database engine and has built-in
Internet connectivity.
Steve Garland
Asta to make it work over the Internet.
>>
ASTA supports 20 Delphi 3rd party Database components and has users using
just about any Database you can imagine. There are royalty free ones such as
Halcyon (dbf), dbisam (www.elevatesoft.com), and MySQL (www.mysql.com) . You
can develop one ASTA client that can be run against say Oracle and MS SQL
Server. We have users doing it now. And all ASTA servers run in all ASTA
threading models as ASTA threads internally so developers don't have to much
with nasty threading code.
ASTA does not require a web server and can scale to the moon using the
AstaAnchorServer.
A great solution with ASTA is with Open Source Interbase 6 and there will be
ASTA Appliances coming that will include Linux, Interbase, and ASTA
pre-installed on Pentium boxes.
This may sound like marketing but we feel that it's just a matter of time
before all database apps use an N Tier design, no matter what database(s)
you use and ASTA will be there to support them all.
In fact, we have had requests to create an ASTA Apollo Server so such
features as our auto client update, provider broadcasts, JAVA clients and
pooled sessions can even be used against dbf files with Apollo.
--
Steve Garland sgar...@astatech.com
Code it once with ASTA and run it anywhere
Win32--> Java-> Coming -> Linux
ASTA Technology Group http://www.astatech.com
tmiller
Steve Garland wrote:
--
Thomas Miller
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
Darcie & Molly
browser and would therefore require a standalone program? Not that this is a
bad thing but I was just wondering...
Thanks,
James
Marc Scheuner <msch...@no.spam.for.me.ca> wrote in message > Not really.
>
> ASTA and dbOvernet are basically the same - in theory, in what they
> try to achieve. They strive to make it possible for you to have your
> client program (a Delphi program) anywhere out there in the world,
> accessing a database located somewhere else, through the internet, at
> a decent speed.
>
> So basically it's breaking up the Delphi app into a thin client
> program and a smart / fat server, both written in Delphi,
> communicating over the internet.
>
> Based on what I know and hear, I'd strongly favour ASTA for this task.
>
>
Darcie & Molly
you access them all from one version? Maybe I'm not understanding what
you're saying here, in which case please except my apologies.
I tried your demo the other night and was very impressed with the speed.
Thanks,
James
Steve Garland <sgar...@astatech.com> wrote in message
news:8enm4e$4r...@bornews.borland.com...
Steve Garland
can
you access them all from one version? Maybe I'm not understanding what
you're saying here, in which case please except my apologies.
>>
3rd Party components. We expect you to know something about how you want to
connect to your database and then we will support your choice with an ASTA
Server.
ASTA licenses per server and the number of clients connected is limited
mostly by bandwidth and your applicaton design.
Steve Garland
used to talk to me more back in the old compuserve days!<g>
<<How do you feel you stack up against Midas?
Midas is fabulous technology and we admire and respect it. With ASTA you can
get full source and we have an unlimited license and we don't require you to
use COM on the server or DCOM for our transport.
ASTA uses plain old tcp/ip with no client dlls or registration needed, no
dcom, no com on the server.
We've had pooled Session threading since ASTA 1 and our servers really scale
well. I know that Midas added ASTA like pooled Sessions in midas 3 called
stateless but I know hear that it can't be used with the midas socket
server. Correct me if I am wrong.
the following is some answers we drafted for an ASTA user a while back when
comparing ASTA to Midas.
=================
ASTA/MIDAS Comparison.
The following are answers to questions posed by MIDAS Guru and all around
great
guy Dan Miser.
>>Does it (ASTA) allow you to do RPC?
That is actually what Josh Dahlby asked me a while back on the midas forum.
ASTA doesn't use a "standard" RPC like DCOM or Corba. Here is a definition
of RPC:
"Abbreviation of remote procedure call, a type of protocol that allows a
program on one computer to execute a program on a server computer. Using
RPC, a system developer need not develop specific procedures for the server.
The client program sends a message to the server with appropriate arguments
and the server returns a message containing the results of the program
executed. "
ASTA supports this is a number of ways.
1. ASTA has a complete and easy to use messaging layer that was designed for
Database application developers to use with no knowledge of sockets or DCOM.
At the lowest level, you can just SendCodedMessage which sends a
Msgid:Integer and a Msg:String. On the server, you code a Case Statement and
do what ever needs to be done.
2. There is also a SendCodedStream and SendCodedParamList. Once we has the
SendCodedParamList we had all we needed as TAstaParamLists can handle any
kind of data including all the normal vcl types as well as binaries and even
datasets and other ParamLists.
3. TAstaBusinessObjectsManager: Here you can define server side methods
(remote procedures if you will) along with their Params. On the client the
TAstaclientDataSet sees a list of available server methods at design time
and pulls down the one to use. When that happens the Params are streamed
down from the server along with the type (datatype, input type). At runtime
you populate the Params and when you set active to true ,the Remote
Procedure is executed and a dataset and any output params are returned to
the client.
There are additional options like to launch the action and return control
immediately to the client (async) for long running server processes. And
also the ability to send back the Field Properties of the attached DataSet.
The DataSet can be attached directly to a server method OR a TAstaProvider
can be used and that DataSet is used by the BizObject Method.
Now get this: any Params defined by the TAstaProvider will come back to the
client. Not only BDE Params (see how non bde midas support is) but *any*
third party param even if it is not a TParam. More on NON BDE support (hey
you started this!<g>)
All of the above supported in all 3 ASTA threading Models.
<<
o How does it handle threading on the server?
Midas 3 introduced Pooled Threading which ASTA has had out of the gate. ASTA
servers can be run in one of 3 threading models
Single
PersistentSession (the old midas one datamodule for each client)
Pooled (the most scalable )
ASTA supports threading internally so you *never* have to create a thread or
do anything with threads. This support extends to the 15 or so current
Delphi 3rd party DAtabase components support by ASTA. Yes, 15 ASTA servers
that all run threaded.
And this is not COM threading but winapi threading which we feel is much
lighter and scalable.
<<How functional is the client side dataset support? Does it do
filters, ranges, locates, indexes, sorting, storing to disk, etc?
>>
I'm attaching an ASTA help file so you can read about this in more detail
but yes. we have filters (string and OnFitlerRecord, locates, sorting (one
fields or multi, asc or desceding on each field). ASTADataSets are fully
streamable and we even have calls like DataSetToString and StringToDataSet
AND we can do this with any TDataSet not just the BDE ones (on the server to
stream to the client).
We don't have indexes but we have defined sorts. We don't have ranges but
you can use filters. Nobody has really pushed us to implement say a FindKey
(whooops recently added 4-15-2000, yes find key to the server! very fast and
efficient)
since our Locate is so fast. We did just recently code a HashTable class to
use in calculated sort fields and have been thinking about implementing
indexes but honestly, you can get by without them.
We also support cloning where datasets can be edited and affect other
datasets. (inserts, edit, deletes are cascaded. midas has this I believe)
<<How complete is its master-detail support? Can you post the
master-detail updates in a single transactions? Can you fetch details
on demand? (With Delphi 4, the details can come in the single datapacket
with the master, one of the cooler enhancements in D4.)
>>
You can post any number of AstaDataSets in one Transaction using the
SendDatasetTransaction call which takes an Array of TDataSet. We support
master detail either through the complete fetching of the detail and using
filters or the firing of a paramterized query on each master change of the
detail (no code required).
We have not done the ftDataSet datatype that midas has to support the
extended SQL syntax introduced by microsoft. We do have a little used
feature we call Cyclops SQL where you can send multiple SQL statements in
one SQLTStrings and a dataset is returned with all the datasets in a blob
field. I did this one day when someone wanted to fetch a bunch of queries in
one server round trip.
<<Does it support constraints defined on the server that are enforced
on the client?
>>
We have contraint support at the field level on the client and we do stream
back field properites using ServerdataSets, TAstaProviders, and
TAstaBizObjects but I'd have to test if we will get back a contraint defined
at the field level.
<<Does it propogate field properties to the client? (Another new
feature in D4.)
>>
yes, using our server side components.
Traditional multi tier midas programing requires a server side provider for
each client. We support this but also pioneered Client side sql.
Run any of our servers canned out of the box (try this with midas) and they
will thread and you can develop and deploy a thin client (no dll's like
midas) app using sql. Converting c/s apps can be very quick using this
technique. We support pure ntier development but don't require it. ASTA
learning curve (no com) can be much less than midas.
<<How does it apply updates on the server? Does it generate SQL based
on the updates? Can you customize how that SQL will be generated (New
feature in D4)?
>>
We support AfterPost and Cached updates using client side sql and the SQL is
configurable (for all our 15 servers!) with lots of properties and events.
(eg post booleans as integers for ms sql server. just a property to set once
on the TAstaclientSocket application wide).
We also support server side sql generation where an oldvalue and current
value dataset is shipped to the server and passed to TAstaProviders which
have events that fire before insert, before update etc AND you can modify
the datasets or handle the sql you want and have ASTA not fire sql.
We also support refetching autoinc fields and default fields for all our 15
ASTA servers (well probably not tested on all of them but possible).
If you have read this far, ask Dan if Midas has this:
AstaProviders and a broadcast ability to send out any change to any
table/row to any interested clients. With NO Code. Instant Auction app with
no code. You will be reading about this in our upcoming (this spring we
hope) review in the Delphi Informant.
<<
o How does it handle reconciliation errors?
>>
We are not as strong as midas on this but we have a conflict management
tutorial to show how it can be handled. we have uses that have code this but
we don't deliver this out of the box. I can argue with you (another day
perhaps) about the cost of going to the server too much for this<g>. but we
can do it.
<<o How much control does it give you over the data on the server?
>>
Not sure what you mean but this but using ASTA with NO COM is pretty easy.
ASTA is a mature product now with many more features that I've discussed
there. Midas is fabulous technology and we certainly don't do everything
they do but:
ASTA has an unlimited licensing available with full source ($249 for source
with the Entry suite)
We don't require any dll's. (the midas client dll's are written in c++)
No DCOM
No winsock2
You'll find our support the best that can be had and we listen to our users
and implement new features almost upon demand. that's how ProviderBroadcasts
came about. After ASTA 2.0 was released a couple of guys wanted to do it so
we coded it. There has been dicussions whether compression is always faster
or
not, so we no provide selective compression on ANY individual query. write
some sql. want it compressed at the server? set a property execute it. Don't
want the next one compressed? turn it off.
Steve Garland
browser and would therefore require a standalone program? >>
Our theory at ASTA is that there IS life beyond the browser and certain
business applications are just too darn hard to maintain and evolve in HTML.
You can run ASTA as an ActiveX and we have companies like seagate software
(now veritas) doing just that for over 18 months with ASTA and Oracle
(direct oracle access server)
We also have an ASTA java client doing database fetches now in beta which
you can run as an applet.
Of course Linux is coming soon also....
tmiller
> ASTA licenses per server and the number of clients connected is limited
> mostly by bandwidth and your applicaton design.
So if I want a DOA, IBX, some DB2 component, and ADO (SQL Server),
then I need to have 4 separate licenses?
Do I also have to have 4 separate code bases?
Currently we have one code base with if statements were we needed.
95 % of our code is the same for all databases.
Steve Garland
then I need to have 4 separate licenses?
>>
license for $4K.
<<Do I also have to have 4 separate code bases?>>
You would be using 4 different Sets of components for servers as I am
guessing you are using the BDE with db2. Yes you could do it with code if
you'd want but we supply server examples as separate exes.
I guess you don't use any visual coding or just bring in different
DataModules depending on which component you are using?
tmiller
Steve Garland wrote:
> You would be using 4 different Sets of components for servers as I am
> guessing you are using the BDE with db2. Yes you could do it with code if
> you'd want but we supply server examples as separate exes.
Right now we support Oracle and IB through the BDE. We are dropping
the BDE and will use direct access components. We are also going to
add SQL Server support in the near future. DB2 is a long term plan.
> I guess you don't use any visual coding or just bring in different
> DataModules depending on which component you are using?
With a TTable there really isn't anything to change. With a TQuery,
rarely. If so, we dynamically change the SQL property at runtime to
match what we require for a particular server. It works fine.
We are changing our accounting system to support n-Tier and looking at swapping
out TDatamodules vs, 'if else' ing the code. I already know how to handle
all of this through Midas (and it is pretty straight forward). I will play with
your product and get back to you with some questions. Do you have
any thoughts on how to dynamically (at runtime) to interact with one
Database module versus another related to your server engine?
Some code to think about:
if gr_BssSysInfo.DBType = 'ORACLE' then begin
dm_DBM := Tdm_BssSystemOrcl.Create(Self);
end;
if gr_BssSysInfo.DBType = 'MSSQL' then begin
dm_DBM := Tdm_BssSystemMSSQL.Create(Self);
end;
if gr_BssSysInfo.DBType = 'INTERBASE' then begin
dm_DBM := Tdm_BssSystemIB.Create(Self);
end;
Each one will have a TProvider of the same name. As far as
Midas goes, it won't know which provider it is talking to, and
won't care. The provider will send off the data to the
TClientdataset and it won't care either. "gr_BssSysInfo.DBType"
is passed to the server at runtime.
Steve Garland
TTables are BDE specific . Tqueries use TParams and TAdoQueries use
TParamters and TOracleQueries (doa) have variables and don't really have
params so I believe you may be entering a brave new work when starting to
move beyond the BDE.
<< if gr_BssSysInfo.DBType = 'ORACLE' then begin
dm_DBM := Tdm_BssSystemOrcl.Create(Self);
end;
if gr_BssSysInfo.DBType = 'MSSQL' then begin
dm_DBM := Tdm_BssSystemMSSQL.Create(Self);
end;
if gr_BssSysInfo.DBType = 'INTERBASE' then begin
dm_DBM := Tdm_BssSystemIB.Create(Self);
>>
Your server would be compiling in components from 3 different vendors and
not something that I would recommend. If you have different Datamodules why
not use them in different exe's?
My experience is that anything that has to do with oracle knows and cares
about as much about sharing as my 3 year old.
<Each one will have a TProvider of the same name
yes, we have users that just run different ASTA servers and they map to the
same server side component name so it's simply a matter of swapping servers
with the same clients. That's what i would recommend.
tmiller
Steve Garland wrote:
> <<With a TTable there really isn't anything to change
>
> TTables are BDE specific . Tqueries use TParams and TAdoQueries use
> TParamters and TOracleQueries (doa) have variables and don't really have
> params so I believe you may be entering a brave new work when starting to
> move beyond the BDE.
We almost never use parameters or variables. We always parse out the
SQL statement. It is much easier to debug your SQL.
>
> << if gr_BssSysInfo.DBType = 'ORACLE' then begin
> dm_DBM := Tdm_BssSystemOrcl.Create(Self);
> end;
> if gr_BssSysInfo.DBType = 'MSSQL' then begin
> dm_DBM := Tdm_BssSystemMSSQL.Create(Self);
> end;
> if gr_BssSysInfo.DBType = 'INTERBASE' then begin
> dm_DBM := Tdm_BssSystemIB.Create(Self);
> >>
>
> Your server would be compiling in components from 3 different vendors and
> not something that I would recommend. If you have different Datamodules why
> not use them in different exe's?
Maintaining 3 set of programs vs duplicating a small part of 1 program. I
will take the duplicating. Does it matter how big the EXE is on the server?
I thought that was the whole idea of this stuff, thick server thin client.
> <Each one will have a TProvider of the same name
>
> yes, we have users that just run different ASTA servers and they map to the
> same server side component name so it's simply a matter of swapping servers
> with the same clients. That's what i would recommend.
Does your server get compiled into my code? Or is it a separate engine?
If it compiled in, I just have to swap in the right unit(s) before compiling?
Steve Garland
SQL statement.
How do you handle blob/memos?
<<Does it matter how big the EXE is on the server?
No.
<<Does your server get compiled into my code?
Yes. The AstaServerSocket has events that abstract the complete database
process and also handles session and thread management as well as a complete
messaging subsystem that allow Database application developers to transport
without knowing anything about sockets.
You are certainly welcome to compile several Delphi 3rd Party Database
Components into one EXE but for performance and sanity purposes we'd still
recommend one chef for each kitchen.
Kelvin Taite
frankness of your reply.
"Derek Davidson" <ddavi...@quickpen.com> wrote in message
news:VA.0000001...@quickpen.com...
> Kelvin
>
> I hope that you don't mind me piggy backing your message here, but
I'd
> like to respond to your question.
>
> I've been using Asta for some while now. I came across it when I
> realized I couldn't code what I needed through Web Hub and force it
> into a web browser. I gave up after three months (long, hard)
effort
> and looked at Asta instead. Three weeks later my app was complete
with
> WAY more functionality and (with the good offices of ASPack) a
simple
> client deliverable at only 650Kb. Stunning stuff.
>
> But why Asta instead of dbOvernet? Personalities & legalities. I
> liked Steve Garland and Ernie Ezis (the co-founders of Asta
Technology
> Group). They clearly loved what they did and were VERY responsive
to
> developer needs. They still are. Only today, Steve EMailed me a
new
> Asta server that promises more speed for use with the app I'm
> producing. You'll always see Steve here on the newsgroups and is
very
> accessible. That kind of support is priceless.
>
I would guess that Fred spends a lot of his time with dbHelpDesk. His
response times to questions and problem solving has been in a matter
of minutes from posting there. My experience has been rewarding as
well with dbOvernet so it concerns me when questions are implied about
this product's stability or capabilities. So far dbOvernet has
exceeded my expectations both in development time and robustness of
product. I do not want to belittle Marc's opinion as as everyone is
entitled, and I know he probably has some good points. I'd just like
to know what they are. (Curiosity only) After buying numereous third
party components it is difficult to choose and sometimes you just have
to go by your gut feel and how it fits with your style of development.
> As far as Fred Dalgleish and dbOvernet went, all I saw was legal
> posturing on who owned what technology and the tenuous relationship
> between dbOvernet and Francois Piettes TCP/IP technology/components
(of
> which I find no mention currently on the dbOvernet web site). I
rarely
> see Fred on the newsgroups (only once in the last year on Feb 15,
2000)
> for the topics that I read. I must applaud Fred though for his
> marketing and the speed with which he brings things to market
(though I
> cannot ratify the stability of the software).
>
I remember that debacle. If I remember correctly it was initiated by
one (unnamed - simply cuz I can't remember) individual and I think it
got way out of hand. In fact, when I selected dbOvernet I felt more
comfortable in my decision because Francois's components was the base
of dbOvernet. (I had already trued his Internet suite) He has a way
of making complicated things seem easy. As for the stability of
dbOvernet I will put my neck on the line and state that I am one happy
customer. I believe that the Delphi world will benefit from having
two products such as dbOvernet and ASTA in addition to MIDAS. The
advancements each make only push the others to push the envelope
(isn't that what competition is all about) Hell, if it wasn't for the
likes of Word Perfect and Quattro Pro features what do you think the
world would have gotten from MS in its office suite.
> FWIW
>
> Derek Davidson
>
Regards
Kelvin Taite
tmiller
>
> Yes. The AstaServerSocket has events that abstract the complete database
> process and also handles session and thread management as well as a complete
> messaging subsystem that allow Database application developers to transport
> without knowing anything about sockets.
>
> You are certainly welcome to compile several Delphi 3rd Party Database
> Components into one EXE but for performance and sanity purposes we'd still
> recommend one chef for each kitchen.
I get the impression that you have an AstaServerSocket per database.
What if I want to create a custom access component? It sounds like
you have some really nice features, I am just worried about
writing my way into a corner. That happened already with Power Builder.
I really don't want to go through that pain again <g>.
Steve Garland
We actually have guys connecting to different interbase gdb files at run
time for remote clients and our odbc server has been coded to allow any
number of concurrent database DSN's to be used for any connected client and
it threads in all our threading models, so maybe I just didn't want to open
up support flood gates for what you are asking<g>
remember, out of the box ASTA supports remote clients running thin client
delphi exe's with client side SQL against compiled ASTA servers with no
changes so our "normal" servers are already setup to handle this under load
(20 different servers).
<<, I am just worried about
writing my way into a corner
the way we tried to abstract this whole server side database process of
sessions and threads is so that you Don't end up in a corner and can easily
move between different database components.
James
> Our theory at ASTA is that there IS life beyond the browser and certain
> business applications are just too darn hard to maintain and evolve in
HTML.
The reason I ask is because I'm thinking of wireless devices (ie Palm and
Windows CE). How would ASTA deal with these?
Thanks
James
tmiller
> writing my way into a corner
>
> the way we tried to abstract this whole server side database process of
> sessions and threads is so that you Don't end up in a corner and can easily
> move between different database components.
That is what I wanted to hear! Like I said, I am looking.
Steve Garland
Windows CE). How would ASTA deal with these?
>>
We hope to have a ASTA conduit for the Palm later this year that would
communicate with an ASTA client and thus any remote database. We are also
even thinking of Palm VII tcp/ip support similar to what we have done for
JAVA.
We have ASTAJava now (we've had an ASTA JAVA messaging class for over a
yera) with Database support that we are testing and getting ready for a BETA
run. It can be used in a JAVA applet or Application.
Derek Davidson
> In fact, when I selected dbOvernet I felt more
> comfortable in my decision because Francois's components was the base
> of dbOvernet.
I fully understand your reasoning. As I recall (and the history is a
bit fuzzy here) there seemed to be a little disagreement between Fred
and Francois regarding the agreement between them. IOW, it was implied
that Fred was making hay at Francois expense. I'd be delighted if
anyone could step in here with factual information regarding that
situation.
> I believe that the Delphi world will benefit from having
> two products such as dbOvernet and ASTA in addition to MIDAS. The
> advancements each make only push the others to push the envelope
> (isn't that what competition is all about)
I wholeheartedly agree.
Derek Davidson
Derek Davidson
You and I have discussed this before, but for the benefit of any interested
readers:
> ASTA licenses by deployed Server exe or you can purchase an unlimited server
> license for $4K.
This is a STEAL. $4K is way too little for an unlimited server deployment
license (and heaven knows, it's not often that I say that!!). I have gladly
paid for that license and will, within the year, be deploying hundreds of Asta
server based software solutions. The savings to me are enormous and I'm
grateful. But here's the thing - I want and need Asta to stay in business -
so I want then to make more profit to allow them to grow by raising the price
(now that I've paid my license fee, I don't mind too much <vbg>)
IOW - The writing is on the wall - expect the price of the unlimited server
deployment license to increase soon!!
Derek Davidson
Bill Carson
>
> As far as Fred Dalgleish and dbOvernet went, all I saw was legal
> posturing on who owned what technology and the tenuous relationship
> between dbOvernet and Francois Piettes TCP/IP technology/components (of
> which I find no mention currently on the dbOvernet web site).
To be fair, that's not an accurate description of postings here. I
participated in the debate that Derek's probably thinking of. It began with
an 3rd party leveraging a question to create doubt into the legality of
dbOvernet. A question posted here was utilized in every way possible to
maximize the illusion of legal conflict. People can judge for themselves
the ethics of that kind of behavior:
http://www.deja.com/=dnc/dnquery.xp?ST=PS&QRY=dbOvernet+V1.5+-+multi-tier+at
+its+best&defaultOp=AND&DBS=1&format=threaded&showsort=date&maxhits=100&LNG=
english&subjects=&groups=&authors=&fromdate=&todate=
I'm sure that following that thread is confusing, but there was absolutely
nothing there that could be interpreted as Fred Dalgleish or Francois
Piette's engaging in "legal posturing" with one another.
> I rarely
> see Fred on the newsgroups (only once in the last year on Feb 15, 2000)
> for the topics that I read.
Just incase this could be misinterpreted as a lack of product support,
people should know that a better technical support than that offered for
free by Fred for dbOvernet is almost unimaginable.
It's handled though a downloadable dbO client app showing dbO in action.
Messages are posted in a searchable newsgroup like fashion, and they're
usually answered immediately. Also, I'd be surprised if anyone using it was
left with the feeling that Fred's replies weren't thorough enough. These
messages can be seen by downloading the app here:
http://www.dbovernet.com/dbohelpdesk.htm (700k)
-Bill
Bill Carson
> anyone could step in here with factual information regarding that
> situation.
Please see my post below.
James
> communicate with an ASTA client and thus any remote database. We are also
> even thinking of Palm VII tcp/ip support similar to what we have done for
> JAVA.
This is really good to hear.
> We have ASTAJava now (we've had an ASTA JAVA messaging class for over a
> yera) with Database support that we are testing and getting ready for a
BETA
> run. It can be used in a JAVA applet or Application.
>
How does this degrade the speed of ASTA?
Steve Garland
> yera) with Database support that we are testing and getting ready for a
BETA
> run. It can be used in a JAVA applet or Application.
>
How does this degrade the speed of ASTA?
>>
The ASTA Server returns the data fast but the JAVA Client must of course
parse it. The key is to limit the result set size.
I'll let you know more as we tune it we are just starting to test the result
set stuff.
Derek Davidson
Thank you for adding some light to a dark subject.
> To be fair, that's not an accurate description of postings here. I
> participated in the debate that Derek's probably thinking of.
I checked the debate you mentioned, and that wasn't it. I was referring to a
message posted on the Dalco web-site itself with links of that (if memory
serves). I mentioned in my original post that I could not find that page
anymore.
> Just incase this could be misinterpreted as a lack of product support,
> people should know that a better technical support than that offered for
> free by Fred for dbOvernet is almost unimaginable.
That's excellent for users of dbOvernet. But for us mere peons that populate
the newsgroups, the impression given is not so rosy. I'm glad you've had the
chance to inform us all of the actual situation regarding support though,
thank you.
Derek Davidson
Bill Carson
I agree, and more! HelpDesk is and excellent tool for ANYONE wanting to
learn more about n-tier development. Many of its FAQ's apply to any n-tier
development environment, and you don't need to be a dbO user to download the
client/viewer: http://www.dbovernet.com/dbohelpdesk1.htm
Bill Carson
It's safe to write all of you application as a client/server first. And the
conversion to dbOvernet will be a little easier if you only use TQuery
rather than TTable components.
Also, conversion will be a little easier if you keep all your data access
components on one or two DataModules. That way when you're ready to
convert, you can just place a ClientDataset next to a Query component,
reproduce the parameters and then search out and modify the code that
accesses the Query to now access the ClientDataset. After testing you
delete the Query and move on the next.
If you're already working with a new IDE on a complex application and only a
small portion is n-tier, you're probably best to do it this way first.
- Bill
----- Original
Kelvin Chua <kel...@accpro.com.sg> wrote in message news:3943d8fb@dnews...
> Hi Bill,
>
> Can I safely assume that I can develop all my program as per normal as
what
> we normally did for Client/Server applications, and incorporate the
> dbOvernet at the later stage?
>
> Thanks.
>
> Kelvin Chua
> SINGAPORE
>
>
> "Kelvin Chua" <kel...@accpro.com.sg> wrote in message
news:3943d769@dnews...
> > Hi Bill,
> >
> > Thanks you very much. All these while I had purchased Delphi since
> version
> > 1.0 until 5.0 but did not really do any productive work with it. Until
> > Version 5.0, I am really impressed by all these additional features
which
> > finally make me jump ship from Clarion for Windows.
> >
> > Thanks again.
> >
> > Kelvin Chua, MBA
> > Singapore
> >
> > "Bill Carson" <newsg...@snailmailit.com> wrote in message
> > news:8i0e8m$bt...@bornews.borland.com...
> > > Hi Kelvin,
> > >
> > > Yes, dbO has been compatible with D5 since just after D5's release as
I
> > > recall.
> > >
> > > It's very simple to work with local data as well as records on another
> > > server over the net. You would just compile dbO's SimpleServer,
without
> > > making any changes, and run it on the inventory system server. Then
> drop
> > > dbO's ClientDataset component into your accounting application, give
it
> > the
> > > appropriate parameters (i.e., server IP, database alias, table
name(s),
> > > fields, usename and password). You can then treat it almost exactly
> like
> > > any other local TQuery component in your application. That part is
> VERY
> > > easy, rewriting an entire accounting application is the hard part. <g>
> > >
> > > If your requirements become more complex, I'm sure Fred would be happy
> to
> > > give a detailed explanation of how to meet them. You can just post
them
> > to
> > > the dbO HelpDesk user forum.
> > >
> > > -Bill
> > >
> > >
> > > Kelvin Chua <kel...@accpro.com.sg> wrote in message
> news:39439fbd@dnews...
> > > > Hi Bill,
> > > >
> > > > Had anyone used dbOvernet?? Is it compatible with Delphi 5.
> > > >
> > > > I would like to rewrite my entire Accounting Package using Delphi 5,
> but
> > > one
> > > > of the pre-requisit is to be able to enter all data on a local drive
> and
> > > > only access the inventory database located at the web server. Can
> > > dbOvernet
> > > > do the job?
> > > >
> > > > Thanks.
> > > >
> > > > Kelvin Chua
> > > > SINGAPORE
> > > >
> > > > "Bill Carson" <newsg...@snailmailit.com> wrote in message
> > > > news:8hpc9g$90...@bornews.borland.com...
Kelvin Chua
Thanks, all details noted carefully.
Kelvin Chua
SINGAPORE
"Bill Carson" <newsg...@snailmailit.com> wrote in message
news:8i2vc3$9i...@bornews.borland.com...