Still would like to use Laz "First Laz Project" ended up in MS Access however...

[mdlueck]

Greetings after several months,

Being project architect / GUI DB developer / DBA / Software Distribution engineer all wrapped up into one, I had to abandon Laz in favor of MS Access 2007 to build this application. ( http://www.lazarus.freepascal.org/index.php/topic,13754.msg74973.html#msg74973 ) No time to deal with the Client / Server environment learning Laz curve on top of all of the other parts of this project.

So, I would still like to consider Laz for either future areas of this application, or for the next application. I ended up pushing Access to the absolute max as a Client / Server front end development tool.

I have double class wrapped data between the forms in the SQL Server back end. As the application starts up, it creates objects for each database table. Those DB objects exist in global memory space for the entire time the client app is running. Then the application boot-strap phase ends and the first real Form opens, and the main non-UI form terminates.

That first form is a list form, so it is a read-only form. All "list forms" in the application are read-only as I did not want to deal with messes of lock tangles. "Double click the record to bring it into edit mode." Behind the scenes, record list forms run a Stored Procedure to select the correct records, and Access DAO.QueryDef objects are nested to download all of the data into an Access FE DB temp table. Then the form builds yet another DAO.QueryDef object also on the fly to populate the form record list control from the FE temp table. ** I would like to find some way to cache data in Laz front ends, not necessarily Access tables, something cross platform would be preferred. **

When records are brought into edit mode, a Stored Procedure to check out that one record based on unique ID of said record is executed. I use ADO Command / Paramemters objects to issue those Stored Procedures. I found a couple of bugs with automatic datatype mapping between Access and SQL Server... when I call the parameter refresh API, something guesses wrong so in those instances I must manually fix the parameter datatype before I execute the SP, else I get a crash. Otherwise it works reliably.  ** Is there something cross platform and comparable to ADO Command / Parameters objects in Laz? **

VBA in Access 2007 can even do real OO things... I coded up an in-memory collection class. I know Laz / Free Pascal can do such. I was surprised to see that VBA could offer such capabilities.

The other layer of class wrapping is what I call my Validation classes. Whereas the DB objects exist the entire time the application is up, the Validation class instances are created by Add/Edit record forms and exist only while that said form is open. So Add/Edit record form opens, in the Open logic there exists knowledge of where to find the ID of the record that form must edit (in the case it is an Edit form), otherwise opens with blank fields in the case of an Add form. Either way said Form creates an instances of the correct Validation class. Let's take the EditForm example. So Form opens, creates an instances of the Validation class, form passes to the validation class the ID of the record it needs to edit, and tells Validate to Populate passing a reference to Me (which is the form itself). Validation class then contacts the DB class object to look up the record matching ID. If successful, Validation class receives the record back form the DB object, then Populate uses the Pointer to Me (MePointer) to Populate the unbound form controls with the record to be edited. If the Commit button is pressed, then the Validation class it instructed to stuck the data back out of the unbound form controls, Validate that no business rules are being violated by any of the proposed data. If bad data is found then Validate turns the form control red, an error dialog is popped, and the DB does not get touched. If however Validation of the data passed, then the Validation class contacted the DB object passing all fields back to it, and calling the correct INSERT / UPDATE method of that class. If the COMMIT succeeds, then the form closes, and the Validation class instances is destroyed along with the form. Hopefully all of this scenario is very doable in Laz. ** Comparing what I am doing with Access ("Client/Server Edition") to Laz with Data Modules... I get totally lost trying to equate Access to the Borland tool style. Open to suggestions in this area.**

Project stats thus far on my lil project...

19525 LOC's in 76 stand along classes / modules
13926 LOC's in 47 GUI forms
Totaling
33451 LOC's in 123 modules

(And that is client-only... ignoring all of the DDL on SQL Server, SP's galore.)

And the project is no where near completion. The client would like me to develop fully Hierarchical  / BOM awareness into this application, whereas currently it uses a flat model. And some other mind-numbing capabilities.

I have had quite many scary encounters with undocumented Access bad behavior. At one point I was certain that I had corrupted the DB. Na, just an undocumented Access bug that if one creates an instance of a Form via its OO Class, then said instance does not have its key set in the Forms collection. Manually spinning through the Forms Collection checking each Form Instance's name is the only way to receive back out of the Forms collection a Form instances in the case that the way it was instantiated was the fancy OO way.

Some times Access will just crash out of the blue for no good reason... and if that happens to be when running a DAO query, then I have to comment out the .Execute in my shared query code, and run the query interactively (through the UI) in order to receive the error, as when driven by VBA code no error will appear, Access simply crashes.

And on and on... (rant) 

So, I'd like to get up to speed on Laz, and then see how the two tools compare. Besides, I run Linux on my non client computers - Laz runs on Linux, not Access! 

Oh, one suggestion on this forum system. A number of other forum systems I am a member of have a view which shows all threads I have ever posted to. Threads with yet un-read posts will show up in BOLD font, and threads I have already read all of the messages in are in normal font. Such would be very handy in this forum system. This is not the same as reviewing all of my posts, as if I replied more than once to a thread, that would show each response. The view by threads shows all threads I have ever posted to, in descending order based on date of most recent post. So if someone replies to a thread I commented on months ago, then right away it bubbles to the top of that list, and is BOLD so I can see that someone replied to that thread.

TIA!
Michael

[BigChimp]

Nice, long post
Some comments/answers:
"I have double class wrapped data between the forms in the SQL Server back end."
Not sure what this means...

"Behind the scenes, record list forms run a Stored Procedure to select the correct records, and Access DAO.QueryDef objects are nested to download all of the data into an Access FE DB temp table."
... I thought your data was in classes?

""** I would like to find some way to cache data in Laz front ends, not necessarily Access tables, something cross platform would be preferred. **""
I think Delphi developers use ClientDataset; you might use bufdataset in FPC/Lazarus if it works for you, or perhaps tiOPF, which is an object-relational mapper. The latter might be a better fit due to what you wrote earlier...
Unfortunately, have no experience with tiOPF and not much with bufdataaset. I'm sure the experts will jump in.

Other alternatives could be an sqlite in memory database, or embedded/on disk databases such as Firebird, sqlite..


"I use ADO Command / Paramemters objects to issue those Stored Procedures." Why are you mixing ADO and DAO in your coding? Ah well, not very relevant to a Lazarus forum...

""** Is there something cross platform and comparable to ADO Command / Parameters objects in Laz? **"" The sqldb database layer has a query object similar to dao querydef; it also supports parameters. It also lets you execute SPs (.Execute instead of .Open)
See e.g. SQLDB Tutorial1 on the wiki and the article on SQLQuery there.
(Sorry, didn't use ADO long enough for it to stick and trying to forget ADO.Net )

"VBA in Access 2007 can even do real OO things..."... which it could since Access 97 (and, a bit more limited, Access 95)

The first part of your Validation class looks more like a data retrieval class to me? But maybe I'm reading it wrong.
"** Comparing what I am doing with Access ("Client/Server Edition") to Laz with Data Modules... I get totally lost trying to equate Access to the Borland tool style. Open to suggestions in this area.**"
Doesn't tell me much. Are you using sqldb (the Lazarus default db components)?
What have you tried?
Suggest you try e.g. the database tutorials in the wiki, and tell us where it goes wrong. A sample program would help too.
Actually, I'm interested in building out the sqldb tutorial1 in the wiki to a more full fledged database tutorial, but that will take time (as well as me learning more techniques in Lazarus, TBH)

"ignoring all of the DDL on SQL Server, SP's galore.)"
Assuming you made a typo and meant DML?
Understand you try to shield/control data access using SPs. Understandable.

"as when driven by VBA code no error will appear, Access simply crashes." Very weird. Even with proper error handling?
Do feel your pain with Access... had some of my own trying to dynamically construct queries that join on mem fields (IIRC). Din't work. Had to use a WHERE clause...

I'd suggest you get started with the tutorials on the wiki. Then build that out to a sample program with all the techniques you want. I'd be very interested in doing the same with you (preferably with Firebird as it's both client/server and embedded, and free).
Perhaps I should finally get started learning/using tiOPF as an alternative, though.

Now over to the experts

[denver]

I am using Lazarus/Dephi for Database + Form Based Application. I would like to share some of my experience:


1. Database connector:  SQLDB or Zeos Lib can access most of the databases ( Both support Parameters in SQL )

2. Server communication: Indy TCP Server is very good for communication with client application. It already handle multi-threads. It will create a thread for each connection and free on disconnect. You don't have to write you own threads handling ( This save a lot of time )

3. Memory Table: I use kbmMemTable for Client-side cache-data.


A Server Program with SQLDB or Zeos and Indy TCP server handle the messages from Client Applications.
For Example

1.  Client program send a message "select * from pcode" to the server.
2.  Server program receive the message and create a connection to DB server and execute the statement
3.  copy the result set to kbmMemTable
4.  convert the kbmMemTable to stream and send back to client.
5.  the client convert the stream back to kbmMemTable and Display it on Form.


Denver

 

[mdlueck]

"I have double class wrapped data between the forms in the SQL Server back end."
Not sure what this means...

I have two levels of Class Objects between the database driver (ADO Objects) and the GUI Forms.
1) The Database Object
2) The Validation Object
and I described both of their purposes in my OP

"Behind the scenes, record list forms run a Stored Procedure to select the correct records, and Access DAO.QueryDef objects are nested to download all of the data into an Access FE DB temp table."
... I thought your data was in classes?
<snip>
"I use ADO Command / Paramemters objects to issue those Stored Procedures." Why are you mixing ADO and DAO in your coding? Ah well, not very relevant to a Lazarus forum...

To get a list of records returned to a FE temp table to display in a record pick list, it is necessary to use DAO.QueryDef objects as Access DB tables are also DAO objects. It is not possible to use an ADO query and store the result set to an Access Table.

Thus for most things I use ADO, and for downloading records to a FE temp table, I must use DAO objects.

""** I would like to find some way to cache data in Laz front ends, not necessarily Access tables, something cross platform would be preferred. **""
I think Delphi developers use ClientDataset; you might use bufdataset in FPC/Lazarus if it works for you, or perhaps tiOPF, which is an object-relational mapper. The latter might be a better fit due to what you wrote earlier...
Unfortunately, have no experience with tiOPF and not much with bufdataaset. I'm sure the experts will jump in.

Other alternatives could be an sqlite in memory database, or embedded/on disk databases such as Firebird, sqlite..

Thanks for the many suggested possibilities... seems I have variety to choose from.

""** Is there something cross platform and comparable to ADO Command / Parameters objects in Laz? **"" The sqldb database layer has a query object similar to dao querydef; it also supports parameters. It also lets you execute SPs (.Execute instead of .Open)
See e.g. SQLDB Tutorial1 on the wiki and the article on SQLQuery there.
(Sorry, didn't use ADO long enough for it to stick and trying to forget ADO.Net )

I like about ADO...
1) ADO.Command objects have the possibility to work with ADO.Parameters objects. This is very much like the ancient DB2 v2 driver for the Rexx programming language that supported the concept of "Host Variables". I posted examples of such issuing an INSERT / UPDATE statement against an Access FE temp table here:

Example of SQL INSERT / UPDATE using ADODB.Command and ADODB.Parameters objects
http://www.access-programmers.co.uk/forums/showthread.php?t=219149

The use of ? as a place holder / substitution for a provided Parameters object... SLICK!!! 

2) With Stored Procedures, there is a .Refresh event to call which syncs up the Parameters list with the particular Stored Procedure to be executed.

Code: [Select]

  'Define attachment to database table specifics and execute commands via With block
  Set adoCMD = New ADODB.Command
  With adoCMD
    .ActiveConnection = ObjBEDBConnection.getADODBConnectionObj()
    .CommandText = "clsObjPartsTbl_LocatePartByID"
    .CommandType = adCmdStoredProc
    .Parameters.Refresh
    .Parameters("@partid").Value = Me.id

    Set adoRS = .Execute()
  End With

So first I define the SP to be executed, then call Refresh, and automatically built is the Parameters list. The only sticky point is I must fix-up the column type in certain cases... like Date datatypes do not map correctly, and VarChar(MAX) I seem to recall. So in those cases I must manually change the guessed Parameter type, then set the Value for the Parameter.

The first part of your Validation class looks more like a data retrieval class to me? But maybe I'm reading it wrong.

Sounds like perhaps. Get/Set mapping between UI controls and Class Attributes is one part. Business rules / validation is the other component of the Validation classes.

I was spending lots of time coding Get/Set mapping and also Valudation rules into the Edit record form... and then having to duplicate the logic in the Add record form. Moving that logic to a class = re-use the code.

"** Comparing what I am doing with Access ("Client/Server Edition") to Laz with Data Modules... I get totally lost trying to equate Access to the Borland tool style. Open to suggestions in this area.**"
Doesn't tell me much. Are you using sqldb (the Lazarus default db components)?
What have you tried?
Suggest you try e.g. the database tutorials in the wiki, and tell us where it goes wrong. A sample program would help too.
Actually, I'm interested in building out the sqldb tutorial1 in the wiki to a more full fledged database tutorial, but that will take time (as well as me learning more techniques in Lazarus, TBH)

In Access, I seem to be relying on Global variable pool that the main() creates a bunch of objects, launching them off into the Global variable pool, then main()_ opens the first GUI form and promptly exits.

In Laz I seem to have to wire each form to a particular Data Module... so shall I create a Data Module for each of my corresponding Access VBA table classes? And then just create many Data Modules at the application start-up, leave them existing, and when XYZ form needs Data Module 123 then it just assumes the Data Module is still in existence?

"ignoring all of the DDL on SQL Server, SP's galore.)"
Assuming you made a typo and meant DML?
Understand you try to shield/control data access using SPs. Understandable.

Data Definition Language

At least that is what DB2 called their table creation scripts 18 years ago! 

[mdlueck]

( Both support Parameters in SQL )

And both support automatic Parameter object creation harvesting required Parameters from Stored Procedure definitions? (I posted a sample in my previous post of using adoCMD / adoParameters objects to execute a Stored Procedure... so looking for something similar to that.)

2. Server communication: Indy TCP Server is very good for communication with client application. It already handle multi-threads. It will create a thread for each connection and free on disconnect. You don't have to write you own threads handling ( This save a lot of time )

So this is for three-tier applications? Clients / Communication Gateway / BE DB

[BigChimp]

"I use ADO Command / Paramemters objects to issue those Stored Procedures." Why are you mixing ADO and DAO in your coding? Ah well, not very relevant to a Lazarus forum...

To get a list of records returned to a FE temp table to display in a record pick list, it is necessary to use DAO.QueryDef objects as Access DB tables are also DAO objects. It is not possible to use an ADO query and store the result set to an Access Table.

No, Access tables are not DAO objects. DAO is just the data access technology most suited to the native Jet database format. It is very well possible to store the results of an ADO query. I must also misremember that I used ADO to populate Access tables.
But I'll leave it at this, this is not an Access forum...

I like about ADO...
<snip explanation>

I'm sorry but suggest you first try out some FPC/Lazarus coding first.... then come back with specific questions unless you already know how Lazarus/FPC sqldb and/or Zeos work (which I don't, completely, I'll be honest). Then you'll also be able to figure out how parameters are used in FPC/Lazarus. If I wanted a refresher on Access use, I'd head over to ACCESS-L (in other words: posting Access VBA code is not that likely to get you help here as a lot of people won't be familiar with it. Explaining the concepts involved would make more sense).

"** Comparing what I am doing with Access ("Client/Server Edition") to Laz with Data Modules... I get totally lost trying to equate Access to the Borland tool style. Open to suggestions in this area.**"
Doesn't tell me much. Are you using sqldb (the Lazarus default db components)?
What have you tried?
Suggest you try e.g. the database tutorials in the wiki, and tell us where it goes wrong. A sample program would help too.
Actually, I'm interested in building out the sqldb tutorial1 in the wiki to a more full fledged database tutorial, but that will take time (as well as me learning more techniques in Lazarus, TBH)

In Access, I seem to be relying on Global variable pool that the main() creates a bunch of objects, launching them off into the Global variable pool, then main()_ opens the first GUI form and promptly exits.

Doing something similar in FPC/Lazarus is certainly possible.

In Laz I seem to have to wire each form to a particular Data Module... so shall I create a Data Module for each of my corresponding Access VBA table classes? And then just create many Data Modules at the application start-up, leave them existing, and when XYZ form needs Data Module 123 then it just assumes the Data Module is still in existence?

Don't know whether you'll need 1 Data Module per form. AFAIU, they're meant to be shared between forms.
In a form, you can check whether objects exist and create them if required. I'd do that, if only for improved robustness.
However, I'll leave it to people with more experience to speak up on this.
Additionally. if using tiOPF, you'll probably have to change this approach anyway.

"ignoring all of the DDL on SQL Server, SP's galore.)"
Assuming you made a typo and meant DML?

Data Definition Language

I know. I'll be less subtle then: why do you need to change table/view/SP definitions while your program is running? Isn't your database well designed?

[mdlueck]

I know. I'll be less subtle then: why do you need to change table/view/SP definitions while your program is running? Isn't your database well designed?

rrrrr????

I never meant to suggest programs I develop are doing such. I apologize for the confusion.

<><><><>

Anyway, I recall now my confusion with Data Modules! The Borland / Free Pascal style is very postured to a single transaction. The way I code in the Object Rexx language, and also am using Classes in VBA is to create a class object per "main focus table". So for example, the Parts table. That does not mean that said object only selects fields from the Parts table... hidden in the Parts table class are some giant queries that join with 8 other tables. However the focus remains Parts based. Joins are used to look up Parts table supporting fields located in other tables.

Said class is able to Look up Parts by ID, Look up Part by PartNumber, perform IfExist based on ID, IfExist based on PN, INSERT, UPDATE, etc...

The graphical Borland / Laz Data Modules, however, seem postured to only one query purpose. THAT is confusing. So must I create many separate Data Modules to interact with multiple SQL transactions involving the same set of tables? Or is there some way to re-use the one Data Modules for several SQL transactions as I am accustomed to doing?

[denver]

2. Server communication: Indy TCP Server is very good for communication with client application. It already handle multi-threads. It will create a thread for each connection and free on disconnect. You don't have to write you own threads handling ( This save a lot of time )

So this is for three-tier applications? Clients / Communication Gateway / BE DB

Yes, this is for three-tier applications. No client-side database driver / connector is required. And I can write server-side SQL Update procedures using pascal in stead of very complex Stored procedure of various database engine.

( Both support Parameters in SQL )

And both support automatic Parameter object creation harvesting required Parameters from Stored Procedure definitions? (I posted a sample in my previous post of using adoCMD / adoParameters objects to execute a Stored Procedure... so looking for something similar to that.)

Parameter ? The following code shown parameters using the Zeos Lib:

Code: [Select]


procedure TForm1.InsertSales(mSalesID, mSalesName: String);
begin
  ZQuery1.SQL.Clear ;
  ZQuery1.SQL.Add( 'insert into salesman ( salesid, salesname ) values ( :salesid, :salesname )' ) ;
  ZQuery1.ParamByName( 'salesid' ).AsString := mSalesID ;
  ZQuery1.ParamByName( 'salesname' ).AsString := mSalesName ;
  ZQuery1.ExecSQL ;
  // .... or add any other additional procedure to update the database
end;



The client-side application just need to pass salesid,salesname to the server program and the server program will use the above code to update the database.

Denver

[ludob]

And both support automatic Parameter object creation harvesting required Parameters from Stored Procedure definitions? (I posted a sample in my previous post of using adoCMD / adoParameters objects to execute a Stored Procedure... so looking for something similar to that.)

Zeos does. It has TZStoredProc. You assign the SP name to StoredProcName and it will retrieve the params for you (or "automatic Parameter object creation harvesting" if you like), no Refresh required. Set the params with ParamByName and then ExecProc (no result set) or Open (result set).

The Borland / Free Pascal style is very postured to a single transaction.

Wrong. You can have as many transactions as you want. There are limitations with some databases (mssql: only one transaction per connection) but there are no language or component limitations.

The graphical Borland / Laz Data Modules, however, seem postured to only one query purpose. THAT is confusing. So must I create many separate Data Modules to interact with multiple SQL transactions involving the same set of tables? Or is there some way to re-use the one Data Modules for several SQL transactions as I am accustomed to doing?

You misunderstood the concept of data modules. Date modules are a placeholder for your database related stuff. So instead of dropping your db connections, queries etc. on a form, you create a data module and declare your db components in that module. This way you can refer in a uniform way to the database components from every form or unit. So the purpose of data modules is to share database components.

[mdlueck]

You misunderstood the concept of data modules. Date modules are a placeholder for your database related stuff. So instead of dropping your db connections, queries etc. on a form, you create a data module and declare your db components in that module. This way you can refer in a uniform way to the database components from every form or unit. So the purpose of data modules is to share database components.

OK, I understood the first part... dropping the DB objects on the Data Modules verses the Form.

Is there someplace you can think of that shows how to use one Data Module for several types of transactions against a certain table configuration, perhaps SELECT / INSERT / UPDATE? I have never seen an example go beyond having a Data Module perform a single transaction. TIA!

[ludob]

Is there someplace you can think of that shows how to use one Data Module for several types of transactions against a certain table configuration, perhaps SELECT / INSERT / UPDATE?

There are several tutorials on the wiki that will help you with that: http://wiki.freepascal.org/Lazarus_Database_Tutorial is a good starting point and contains many links to other pages.

Again a data module is just a placeholder. It doesn't do anything. TSQLQuery (or TZQuery on Zeos) and their associated datasets are the components that work with tables and views. In some cases they'll even create the Insert/Update/delete queries for you starting from the Select query.

Note also that SELECT / INSERT / UPDATE are in DB lingo not transactions. A transaction is a set of queries that is to be applied as a whole or not at all. They are grouped in a begin (sometimes implicit)  ... commit | rollback clause. In DB2 they call it also a UOW, unit of work. Using the correct terminology would help in getting the right answers.

[mdlueck]

Thank you, ludob.

I forgot to add... Wiring up DB components to see the Borland tropical fish eventually gets boring!  Yes, have come a long way since the initial release of Delphi.

Thank you for mapping my terminology to current terms. I have worked with so many different technologies over the years I tend to get the specific terms all jumbled together in my head. I apologize for that. As one example, back in the old DB2 driver, what ADO calls "Parameters" are called "Host Variables", as just one example. So when I first was learning Access/VBA, I was looking for "Host Variables" and not finding much at all.

I tend to see database applications in very deliberate action ways. (aka what I call a "transaction") I am opposed to "spreadsheet databases" where users are allowed to go free-wheeling editing any old record they like in a data grid view. In my mind, data grids are to be read only. Double click a blank row to receive an AddRecord form (or push the Add/Insert) button on the record list form. Said AddRecord form should have a Commit and Rollback button. Pushing Commit should lead to a SQL INSERT after validation rules, etc... The EditRecord form should be about the same, only pressing the Commit button on that form leads to a SQL UPDATE. and so on...

And I even support more color options than black... aka Ford Motor.

[ludob]

Double click a blank row to receive an AddRecord form (or push the Add/Insert) button on the record list form. Said AddRecord form should have a Commit and Rollback button. Pushing Commit should lead to a SQL INSERT after validation rules, etc... The EditRecord form should be about the same, only pressing the Commit button on that form leads to a SQL UPDATE. and so on...

When using datasets, the AddRecord and EditRecord form are one and the same. To add a record you do Dataset.Append and to edit a record you do Dataset.Edit. When applying the changes, the dataset will use an insert or update statement according the case.

I forgot to add... Wiring up DB components to see the Borland tropical fish eventually gets boring! 

Well, if you have seen the fish, you should have already a good understanding of what the database controls can do for you

As one example, back in the old DB2 driver, what ADO calls "Parameters" are called "Host Variables", as just one example.

That was IBM in the old days when they called everything different from the others to outsmart the competitor (they wore also white socks). To bind host variables with the DB2 CLI API you have to call a function called SQLBindParameter  In the end they only confused themselves and their customers.

[KpjComp]

Code: [Select]

Date modules are a placeholder for your database related stuff
I'd actually class Data Modules even more generic, there just a dummy placeholder for shared resources.  eg.  ImageLists also fit nicely there.

But once advantage too using Data Modules for data only, is when you wish to make your DB multi-threaded.

Saying that, I personally don't use Data Modules for data.  I like to create separate classes instead.

@mdlueck: 

From reading your detailed post, I'm sure Lazarus will do everything you need.  The biggest issue is understanding the wording/concepts that you used with Microsoft.

eg.

Then the application boot-strap phase ends and the first real Form opens, and the main non-UI form terminates.

I've never heard the term boot-strap phase ends used to open a Form in Delphi/Lazarus.   And the main non-UI form terminates, in Delphi/Lazarus you would just say Close/Frees, the only terminate is when your App closes.

[mdlueck]

To bind host variables with the DB2 CLI API you have to call a function called SQLBindParameter 

Perhaps in the C API such was necessary. That was hidden from using such capabilities in the Object Rexx language.

With that old driver, Host Variables were sort of spooky... no need to load variables into any sort of "transporter" to get them to the database. Just happen to have a local Rexx variable of the correct name laying around in the local environment, and when the SQL was executed magically the contents of that variable was known by the DB2 server.

In the end they only confused themselves and their customers.

Which perhaps is what I face now, having SEVERAL vendor's worth of technical details all in my head. Borland (Paradox), IBM (OS/2, Rexx, DB2) and Microsoft all mixing. Toss Linux into that mix... I started out on RPM based distros, then switched to Debian in 2003/4, so DEB based distros since then. I feel uncomfortable trying to remember how to get XYZ done when I face a RPM / CPanel based server now.