🚀 go-pugleaf

"Vladimir Afanasyev" <avv@systema.kiev.ua> wrote in message
news:3fa7ea09$1@newsgroups.borland.com...
>
> Hi,
>
Hi Vladimir,

Thanks.

> >
> >Hi Vladimir,
> >
> >Yes, I tried it, but I had trouble following some of it because there is
no
> >explanation of what is happening, or supposed to happen.
>
> Yes, you are right but when idea comes it's so quickly that
> no time for comments - only for code. Sorry.
>
> Now when I had created my site I will write some article on it
> that refer to my download. But my English bad so no warranty
> again.
>
Well, if you would like some help, just ask.  I am sure there are enough
native english speakers here who would help, and some of us are experienced
educators and so can be expected to have greater language skills than
average and to be able to comment on the educational utility of different
aspects of your sample code (e.g. I have taught environmental modelling and
scientific computing to support modelling to young adults who were life
science students and who had never written a program before).

> Any automating idea (for Word, Excel, ADO, MS Project) revolve
> on object model and my samples come from it.
> In most cases Variant type gives many similarity with Visual
> Basic so when I create download I study VB samples from
> Microsoft Platform SDK.
> As I understand your code you try to use SQL for creating
> tables but in SDK help you can see samples with object
> Table, Columns, etc:
> (VB)
>
> The following code demonstrates how to create a new table.
>
> [VB example snipped]
>
Yes, I figured this out from your example code, and had it working (but
hadn't tested it WRT inserting data - I just looked at the presence of the
tables, using MS Access, after shutting down my program).  I went on,
though, to look at creating tables using SQL.

> The right idea it is redo this code. Try it.

The trouble with this is that I am working toward building my own
application framework that is platform neutral, using template classes for
the various controls I'd use, with specializations for classes from
different UI libraries (such as VCL and wxWindows) to handle differences
between then, and I want my DB code to be as portable as practicable.  While
I AM using ADO, I am trying to minimize the dependance of my code on it so
that, in due course, I create my own DB class, which handles making a
connection to MS Access or DB/2 or Oracle or Interbase, closing the
connection when appropriate, and passing SQL statements to and retreiving
record sets from the database.  In this way, if I find I should port my
application to Linux, or some other OS, all I need address in my code is the
implementation of my DB class (which on Linux may end up using corba instead
of COM).  I am a bit unclear at this stage, as, although I like the idea of
automation (and would be especially interested in seeing how MS Project, MS
Word, and MS Excel are automated), I do not know what, or even if there
exists, standard automation methods are available to use on Linux.

I have a bias favouring languages like FORTRAN, C/C++, and SQL, over
languages like VB, Delphi, Perl and technologies like VCL and ADO, even
though I use them when appropriate, because the former have ANSI/IOS
standards while the latter are whatever the vendor says they are and there
is no guarantee that what I produce today will even compile, let alone work,
tomorrow.  If I use a standard compliant language and design, and exploit
that to the greatest extent possible, then what I produce today may well
remain useful twenty or thirty years from now.  After all, some of my
favourite number crunching libraries were first written in fortran over
thirty years ago, and have had all that time to mature, eliminate bugs,
improve efficiency and library design, &c.  This is something that is highly
unlikely with any language or technology that doesn't have an ANSI/ISO
standard to provide some stability.  We have no way of knowing how long
proprietary languages and technologies will survive and so with the we know
we can't ensure code we produce using them will have an adequately long
useful life.  While I have a basic knowledge of Delphi, I don't use it much
because I must take the viewpoint that whatever I do with it must be a case
of write once and discard (or deliver WITHOUT ongoing support) since there
is no way I can know that it will still exist in ten or twenty years, or
that, if it still exists at that time, what is present then will be
compatible with what I produce now.  This is a marked contrast to FORTRAN
where, for example, most FORTRAN 77 code will still compile with the lastest
FORTRAN compilers, and even that which doesn't needs only relatively trivial
changes to compile now (this is largely true even for the FORTRAN IV code I
have seen or used).

I will try your approach again, to see if it gets me past this particular
hurdle (I am a pragmatist and so will use whatever method is necessary to
get my product out as quickly as possible), but the question remains: "The
SQL statements shown for creating and populating tables previously SHOULD
have worked, so why didn't they work?"

Thanks again,

Ted