Re: Nameless CREATE

On 19 Dec, 23:18, Josh Grams <j...@xxxxxxxxxxx> wrote:
X is defined in execute-parsing-wordlist.
...
execute-parsing uses >order to add execute-parsing-wordlist to the
top of the search order so that EVALUATE will find this X.

Thanks for that explanation.

Now something *I'm* not clear about. You posted this example earlier:

This approach facilitates use of the data - for example a simple
inventory report would be:
BEGIN
QUANTITY . 5 SPACES PARTNUMBER . CR
NEXTROW
FALSE =
UNTIL

It seems silly to me to be jumping through hoops to define separate
words that access each node. Why aren't you just naming the nodes
QUANTITY and PARTNUMBER, and using some sort of accessor word to fetch
the values? That is:

CREATE QUANTITY
\ ...allot and initialize it...

: VALUE ( node -- value ) 16 + @ ;

BEGIN
QUANTITY VALUE . 5 SPACES PARTNUMBER VALUE CR
NEXTROW
FALSE = UNTIL

Or...if having that extra word bothers you, you could make VALUE the
default action for your nodes, and use >BODY to get at the body when
you need to do something else with it:

: create-node CREATE ( ...allot and initialize it... )
DOES> VALUE ;

\ store the value
29 ' CREATE >BODY 16 + !

I can think of other options too, but I don't know enough about your
project to have any idea what might work best...or even if you're
interested in switching things around, since you have a working
solution already.

--Josh

The starting point is either an existing database or one that is
newly
defined using e.g., the Microsoft Access graphical user interface
or via DDL (Data Definition Language) commands issued by a Forth
or other programming language.

In any event, all the field names, data types, sizes, etc.,
have been defined during design of the database.

What you are proposing would involve duplication of effort since
during the data retrieval/ analysis/ reporting process, you would be
manually redefining all aspects of the fields in the Forth
programme.
This involves both effort and also introduces the possibilities of
mistakes/ inconsistencies being introduced.

The idea is that the design of the database, data retrieval and
analysis/
reporting stages should be as independent as possible whilst not
involving
duplication of effort. ODBC provides functions via which it is
possible
to determine the structure and details of the database.

The general process involved in retrieving data can be summarised as
follows:

Define a connection to the database.

Prepare and Execute an SQL query to define results to be retrieved.
SELECT * FROM TableA WHERE ... ORDER BY ...

Do a "link and describe" process for all columns related to the query.
In the Forth programme, "linking" involves creating the linked list of
nodes
corresponding to each column, each of which has a structure that can
be used
to store all details regarding the particular column.

"Describe" involves issuing an SQLDescribeCol function to ODBC
requesting
that it returns details of all columns in the query into the prepared
structure.
Thus, ODBC "tells us" that column 1 is called QUANTITY and is an
Integer
together with other details.

Then a "binding" process which involves issuing an SQLBindCol function
to ODBC
informing as to how the particular data type should be converted
and the address of the structure into which the data returned should
be mapped.

Then I run my DefineNames code.
Now QUANTITY . produces 29.
Then NextRow QUANTITY . produces 43
(actually NextRow will need to return a flag indicating whether or not
the
end of file has been reached).

The main aspect to appreciate is that I have not had to tediously re-
specify in
code that there is a field called QUANTITY and that it is an
integer.
Equally, I can issue DESCRIPTION TYPE and text is generated.
Actually I am defining various versions of the column names
such as NAME, NAME@, NAME. so that I would just issue QUANTITY@ or
QUANTITY.

Using Visual Basic it is possible to do similar without all the
complications
of having to set up all the data structures or field names.
After defining a connection to the database and executing the query,
you can just write stuff like:
myString = myString & rs1("QUANTITY") & SPACES(5) & rs1("DESCRIPTION")
& vbCRLf

Alternatively,
myString = myString & rs1("0") & SPACES(5) & rs1("1") & vbCRLf
where 0 and 1 relate to the column numbers (probably the quotes are
not
required for these numbers).

I shall also define words such as FIELD. and COLUMN. which I can
use
as follows:

1 S" QUANTITY" FIELD. 5 SPACES 1 S" DESCRIPTION" FIELD. CR

1 0 COLUMN. 5 SPACES 1 1 COLUMN. CR

Regarding ODBC (Open Database Connectivity), the basic concept is
sound
and it offers considerable power and flexibility.
However, as for all things which originate from Microsoft,
the drawback is that it is over-complex and the documentation
difficult to understand.
There are around 60 functions and probably about 1000 pages of
documentation!
Here is a site that provides a reasonably short overview
and readily understandable explanation:
www.anaesthetist.com/mnm/sql/odbc.htm

Incidently, I noticed that there are some recent postings on the
Forth Inc. SwiftForth forum regarding use of Forth with SQLite
databases.
The complete SQLite programme occupies less than 250k which opens up
additional applications in high end embedded systems.

I hope that my explanation has at least partly answered your query.
The shorter answer would be that I do not name the nodes but rather
have to rely
on names returned into the data structures by the ODBC function calls.

I have a rough working prototype but it is not too late to change
things.
Much additional functionality is required before I have usable general
purpose tools.
I welcome any ideas that could be incorporated.

Digressing from the main topics, there is one aspect on which I am
struggling
at present and should appreciate if anyone has any ideas ...

For columns of binary type, storage surprisingly seems to involve
two bytes per character. My understanding is that the binary data
type is
essentially much the same as character data type apart from all 8 bits
of a
byte being considered relevant rather than just 7 and null values
being permitted.
Consequently, there should be no reason why I can't store 7-bit ascii
characters
in the byte of a binary data field.

I defined a column to be of the BINARY type of size 50 using the SQL
command
ALTER TABLE tablename ADD COLUMN BinaryColumn BINARY(50)

Then I tried to store the (27 character) text string:
Text in BinaryColumn field.
into the field.
This failed as a result of the field being considered to be too small.

To store up to 50 characters I need to specify BINARY(100).
Access then shows that the maximum field size is 100, as one would
expect.

On retrieving the data via ODBC functions into the Forth programme
I observe the following:

BinaryColumn DUMP
1C988A 54 00 65 00 78 00 74 00 20 00 69 00 6E 00 20 00
T.e.x.t. .i.n. .
1C989A 42 00 69 00 6E 00 61 00 72 00 79 00 43 00 6F 00
B.i.n.a.r.y.C.o.
1C98AA 6C 00 75 00 6D 00 6E 00 20 00 66 00 69 00 65 00
l.u.m.n. .f.i.e.
1C98BA 6C 00 64 00 2E 00 00 00 00 00 00 00 00 00 00 00
l.d.............

So, every second character is a 00

The ODBC functions show the data originating as SQL_BINARY from the
database.

For the "binding" process, I use the default SQL_C_BINARY type for
the
conversion process.

Nowhere in the documentation does it explain why the data occupies 2
bytes
rather than 1 byte! Equally, my extensive search using Google has
failed
to find any explanation.

I have the same problem with columns defined using SQL as IMAGE
type.
These are variable length binary fields that could be used, as the
name
suggests for storing images, etc.

Access shows such fields as being of the OLE Object type.
The ODBC functions show the data originating as SQL_LONGVARBINARY from
the database.
Again, for the "binding" process,
I use the default SQL_C_BINARY type for the conversion process.

I should much appreciate if anybody knows why the data occupies
twice the expected size!

Best Regards,
Douglas

.

Relevant Pages

  • Re: fields queries and utter disaster
    ... Unfortunately the \c ODBC DATABASE field switch is not supported in Word ... of course supports ODBC connections but Word ... Mac Word Test ... suggests that it should be possible to use query files (cf. .qry/.dqy ...
    (microsoft.public.mac.office.word)
  • Re: [VW 7.3.1] ODBCConnection
    ... I played around with a few combinations on the connection string and ... with a trusted SQL Server connection. ... there are differences for database connects. ... > any database specific odbc drivers. ...
    (comp.lang.smalltalk)
  • Re: Serious Problem with Date in RecordSource
    ... Yes, this is ODBC data, not JET data, so some if the things I suggested ... >> c): Decompile the database. ... Still in the code window, choose Compile from the Debug menu. ... rather than allenbrowne at mvps dot org. ...
    (microsoft.public.access.formscoding)
  • Re: CDatabase, CDaoDatabase
    ... raw ODBC calls ... DAO will outperform ODBC (and so CDatabase) considerably in single user ... There is considerably more to database performance than making quick ...
    (microsoft.public.vc.mfc)
  • Re: CDatabase, CDaoDatabase
    ... raw ODBC calls ... DAO will outperform ODBC (and so CDatabase) considerably in single user ... There is considerably more to database performance than making quick ...
    (microsoft.public.vc.language)