ODBC connection to MS SQL 2000 help needed

[Jan Schenkel]

--- Lynn Fredricks <lfredricks at proactive-intl.com>
wrote:
> 
> If you were to prioritize improvements to database
> access in Revolution,
> what would you want?
> 
> Best regards,
> 
> 
> Lynn Fredricks
> Worldwide Business Operations
> Runtime Revolution, Ltd
> 

Ooh, where shall I start? *grins as he cracks his
knuckles*

Don't get me wrong: one of the reasons I fell in love
with Revolution, years after HyperCard lured me into
programming, was the database access functions. Along
with the internet stuff, zippy speed and
cross-platform development on top of the elegant xCard
paradigm.

But it's just one of those areas where you get all
excited about those one or two little extra things
that would make a solid product stellar. So here comes
my list:

1) Native drivers for as many databases as possible -
evangelize the platform and convince the database
builders to write the drivers themselves ; if they're
not helpful, sit down with companies like Actual
Technologies that produced ODBC drivers for Access and
MS SQLServer for Mac.

2) Improve the ODBC revdb driver so that it gives us
the best options where available, and uses its own
temporary storage mechanism to compensate for
forward-only cursors.

3) Document and expand the 'revdb_tablenames()'
function so that we can get the names of tables in a
database without having to construct queries that are
database dependent

4) On a similar note, add a 'revdb_fieldnames()'
function that returns a list of the fields in a table
for a given database connection

5) Add convenience functions that return single
records or entire record sets as an array or in XML
format; not that important as we can script this
ourselves, but C code might do it faster, especially
since it's close to the data and doesn't have to
communicate through the XCMD layer

6) Improve transaction support: right now you can
commit and rollback transactions, but you can't tell
the DBMS when the transaction starts? If possible,
allow nested transactions.
(You could call this 'revdb_starttransaction', and
make it a function that returns a transaction ID
number that we can use to commit or rollback the
individual transactions; if the database doesn't
support transactions, return a string with a
'revdberr' message)

7) A little more exotic now: could you make the revdb
library run in its own thread, and allow callbacks,
similar to the socket communication model?
(That way we could just fire off a lengthy query and
the app UI remains responsive; we could get the data
back in portions and start filling in table fields
progressively. Bonus points for the ability to cancel
queries that are in progress.)

Of course, I'm a tad biased, as my day job is building
Finance and ERP solutions on the Progress OpenEdge
platform. Items 2 through 4 should help anyone connect
to databases, and Item 1 is no surprise either. Item 5
is something that we can do ourselves, while Items 6
and 7 will make it more attractive for the Enterprise
market.

My two eurocents,

Jan Schenkel.

Quartam Reports for Revolution
<http://www.quartam.com>

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com