|
Most Database developers getting exposed to Delphi for the first
time, run the DBDEMOS examples that are based on Paradox and xBase
tables. Paradox is so easy to use. Rich Data Types, good performance,
Delphi takes care of all the record locking on the network, in grid
edits with data aware controls are very easy to use, SQL Support,
plentiful options of Delphi 3rd party controls that work with the
Delphi standard TQuery/Table BDE components. Develop in Paradox and
when you are ready to upsize to MS SQL Server 7 just run an upsizing
Wizard and your app will run fabulously unchanged.
If you buy that first paragraph, we have some land we would like to
sell you that I am sure you would be interested in. The real truth is
that Paradox and the network locking scheme is a nightmare, installing
and maintaining the BDE is horrific, and the idea of taking a TTable
based Paradox app that uses SetRange and FindKey calls and porting that
code to client/server databases that expect you to understand the
concept of result set is almost enough to get you certified as insane.
There is a world of difference between Desktop coding techniques and
client server techniques. Nativagational developers are from Mars and
client server developers are from Venus. Make the TDataSet call to
recordcount against MS SQL Server 7 and an additional forward only
cursor is opened to execute a Select (*) count from MyTable. Use Data
Aware controls and you may lock pages of data with databases that don't
support row level locking. Even if they do support it there is always a
cost to Data Aware controls and mostly that cost is hidden form you in
performance hits or concurrency issues. Add a row to a table with an
AutoInc value and it doesn't show up until you do a select. Call
refresh and it doesn't go to the server, what does it do?
Take a Developer used to Big Iron databases and you probably won't
see a grid in his application but a navigational bar as he is all too
aware of the cost of bringing over gobs and gobs of data and allowing
any of his users of having even the remote possibility of being able to
select all the rows of a 25 million row table. He is used to writing
custom SQL to do updates, inserts and deletes and has a bunch of
"tricks" to coax performance out of his database.
As you add users to your Paradox application it will hit a wall one
day and that day is sooner than later. Develop an efficient
client/server based system and the users still want to see more grids
and Data Aware controls like their cousin did in that Access
application they use at their Church.
What if we could give you a Database solution that could use Data
Aware controls, scale to the moon, run over the Internet, deal with
AutoInc and default values transparently and with no code, write all
the SQL for your insert, update and delete statements for you and post
them very efficiently to the server, conserve database resources to a
degree never before imagined and still give you fast performance even
over slow lines and could run against different Databases? What if
there were never have any setup or install issues and the client would
be guaranteed to always have the most current version of the
application? What if changes made to the database by other remote users
that were important could be broadcast to interested users? What if you
could write as if you were using Paradox but really it was using Oracle
or MS SQL Server or Open Source Interbase 6?
Welcome to the world of ASTA.
ASTA allows Database application developers to concentrate on what
they know rather than wrestling with their Database to force it to
behave like Paradox Tables on steroids. ASTA handles performance
issues, efficient network communication, SQL Generation, concurrency
issues, transaction control while allowing the developer to get work
done by coding at the TDataSet VCL Level. ASTA was designed to perform
well over slow lines and to leverage Database Resources so that users
can be added with no change to the client application.
Why worry about if RequestLive is true or if your AutoInc will show
after you fire an insert statement. Why think about arcane issues like
only one forward only cursor allowed or what cursor library to set
your database session component to. Meet your deadlines. Design your
App with ASTA and run it Single User, on the LAN, WAN or over the
Internet. We are not saying it is simple to write a client/server
application that can be used against a variety of Databases like
Oracle, MS SQL Server or Interbase but with ASTA it will be a lot
easier. One Client application that can connect to any one of 20 ASTA
Servers using Delphi 3rd Party Components. In fact some 3rd Party
Components that ASTA uses on an ASTA Server would be virtually unusable
if trying to write an application with but since ASTA servers require
just a small subset of any Delphi Component and since ASTA servers use
thin, fast pure SQL and Win32 threads these components work great and
you still use the TAstaClientDataSet the same way no matter what
Database Component is used on the AstaServer.
Client Server Manners
Now you will have to develop good client server manners. This means
not fetching that 200,000 row table with a Select * from Customer SQL
Statement. You must follow the Client Server Prime Directive.
Fetch Only What you Need When you need it.
Don't use Select * use Select Last, First, Age, SSN from Customer.
Name your fields. Write SQL predicates Where State='CA' and Last like
'SMITH%'. When you go to a server, get a digestible, transportable
result set not the whole state of Texas, just a neighborhood from one
city. Users can't really browser 100,000 rows but they can digest 200
rows.
You like beer? Learn to drink it in a straw and it will be cold and
flow freely.
Data Aware Controls
ASTA uses in memory datasets that are copies of the actual data from
your database. Since they are copies and they are in memory there is
never any cost to data aware controls. Forget the concept of
RequestLive, forget the concept of Ttables, result sets rule in this
world. Copy the data, work on it remotely. Post it back to the server
when you are ready. Now there is no cost anymore to DataAware controls.
You cannot cause any concurrency problems by trying to lock rows or
browsing tables and triggering page locks. ASTA always makes a copy of
your selects and streams them back to remote users who own their own
data.
For you Navigational TTable Users
Forget about indexes. Create your tables with indexes on fields that
will be searchable. You know how to do this. Then let your database
decide how and when to use indexes. SetRange no longer applies. Learn
to use SQL to write predicates to limit your data to get manageable
result sets. Want to call FindKey? Forget it. Select YourFields from
YourTable that Meets Your Criteria. We want a copy of the Data and we
want to get it and get out as fast as possible.
Conserve Resources
The most precious and time-consuming operation is connecting to your
Database. The most popular use of that Database connection by Database
Application users is:nothing. They mostly sit there with idle time. Why
take up a Database connection when they are viewing data, or printing
reports. Share that connection and that is what all ASTA servers can do
with ASTA's Pooled Threading Model. At Server start up a Pool of XX
number of connections to the database are created. When remote users
come in to copy their result sets, they check out a Session from the
Session Pool and do their database work in a thread. They may start
transactions, they may do selects, they may issue update, insert or
delete statements. The Session is theirs to use while they need it. But
when they are done with it is put back in the pool so that other users
can use it. This gives you scalability.
AstaClientDataSets Make Development Easy
AstaClientDataSets have been designed to allow you to write client
server type applications as Desktop applications against any Database
with little resource consumption and are optimized to run over slow
lines. Write a select statement and then put the AstaClientDataSet in
Cached EditMode and you won't have to write any more SQL for inserts,
updates or deletes. Have an AutoInc Field or OracleSequence? Set some
properties and sit back and enjoy the ride. Default values created on
the server on triggers or as defined by your database? Select which
fields you want to be refetched on inserts or updates and ASTA will
handle it for you. These are in memory tables so use normal VCL
TDataSet methods like Append, Edit and Post. Call
ApplyUpdates(usmServerTransaction) and ASTA will generate any SQL you
need, go to the server in one efficient trip, start a transaction, post
each SQL statement, and Commit or Rollback the Transaction as
appropriate.
Lots of Users
If you are worried about scaling your application you can stop and
go and and play golf. ASTAServers make such efficient use of Database
Connections that one connection can easily server 10-20 users depending
on the design of your application and the size of your result sets you
are fetching from the server. Want to add more users? Add another
ASTAServer and use the AstaAnchorServer for load Balancing. Users
connect to the Anchor and are handed off to the next available ASTA
Server. The most critical resource moves from database connections to
bandwidth. Now go and buy some more T1 lines if you want to scale as
bandwidth is the most precious resource in the world of ASTA.
Installation Issues
The Clients need to download the Exe. That's it. No setup. No DLL's.
No registration. No nothing. ASTA puts the Install package vendors out
of business. Register a new version of your ASTA Client Application
with your ASTA server and the application will always be guaranteed to
be current with ASTA's auto update feature.
Database Pain
As experienced Database Application Developers, we at ASTA think we
have toiled in the same fields, chased the same tired team of database
horses around the dusty rows of newly planted table rows. We have tried
to design ASTA so that you won't get that dull ache in your lower back
when you do database development with ASTA and you wont' be wrestling
with workarounds AND your application will be able to scale and run
over the Internet. The perhaps you can go play golf or hang out at the
beach where we all really belong.
|
Support 
