At 09:01 AM 05-10-01 +0800, you wrote:

>It was built as Dialect 3. The problem with the date (data) is that it is
>from a Dbase III+ file, and there is no datatype like TIMESTAMP, there
>is not even one for TIME.

Do you _want_ to store data and time separately, or would you prefer to amalgamate the two Dbase columns as TIMESTAMP?

> > > > UPDATE MYTABLE SET MYDATECOL = CAST('9/19/01' as DATE)
> >
> > >I tried the CAST statement, but same error.
> >
> > What EXACTLY is the error message ?
>
>Sorry, it wasn't an error message when I did the CAST, that worked fine,
>no messages. The only error msg is
>
>Project IBOQuery.exe raised exception class EDBEngineError with
>message 'General SQL error.
>
>Column error.
>Column unknown
>MSG_DATE
>Client SQL dialect 1 does not support reference to DATE datatype'.
>
>Click OK, and "Run" and I can view the data.
>
>BTW, I don't get the message when I just run the executable IBOQuery,
>only when I use F9 from Delphi.

Now I'm confused. If F9 (which does a compile and run) is throwing this exception, presumably the executable is not being built. So the exe you are _able_ to run must be an old one, right? What was different about the environment in which you ran that? It seems as if the client library currently being accessed is the wrong one...

>If it's no big deal, and I have 100%
>assurance that a user isn't going to have the program abort, then I'm
>prepared to ignore it.

I'm not at all convinced!

>I can't see such a help file in either D6 or Interbase help files.

The Data Definition Manual is not a help file - it is part of the seven-volume InterBase documentation set. It's in Adobe PDF format so you will need Acrobat Reader 4 (free from www.adobe.com). For a link, go the Documentation Index section of the interbase2000.org website http://www.interbase2000.org

>
> > What kind of control are you trying to view the blob column in? A TDBGrid?
>
>Yes
>
> > AFAIK, the VCL TDbGrid doesn't support displaying blobs in a grid.
>
>How does IB_SQL do it then, the grid display shows blobs just how we
>need them.

IB_SQL uses the native IBO data access components and their controls. The TIB_Grid is a very smart grid....but it is not compatible with the TDataset-compatible data access components.

> > Display a TDBMemo alongside the grid, linked to the same datasource and to
> > the blob datafield; then, as you scroll through the grid you will see the
> > contents of the blob field.
>
>I think I'm getting too confused because I'm trying to skip learning
>Delphi and jumped straight into IBO. All we need is a TDBGrid type
>display for a single table showing the blob column (user can dble-click
>to open) and the other 3 columns. An IBOQuery runs when the user
>presses a button. I don't want to go near the BDE.

We are not talking about going near the BDE. The data access components you are using (those with the TIBO* prefix) are designed to _emulate_ their BDE equivalents, so that you can use the TDatasource and the controls from the native Delphi VCL.

To use the "native IB Objects" controls (TIB_Grid, TIB_Edit and so on) you need to use the TIB_* data access components and the TIB_Datasource.

>Maybe I should stop wasting your time (much appreciated though) and
>at least go thru the IBO tutorial.
>
> > NB, make sure that you instantiate the virtual field objects of your
> > dataset (set the query Active,
>
>When I tried that, it was the same message I got when I tried to change
>the Datfield property of the TDBMemo object, the msg is
>
>ISC ERROR CODE :335544344
>
>bla,bla,bla
>
>I/O error for file 'C:\Program Files\......\mastsql.gdb'
>
>of course the file doesn't exist, but I searched the source, and changed
>the value to point to the GDB I want to use. Where is it looking.

What you need to do is set the Path and Server properties in your TIBODatabase and then go to its Databasename property and give it a "friendly" name, e.g. MyDb. Then, go to your IBOQuery and select MyDb from the drop-down list.

>I notice in the TDatabase , it has an alias dropdown, which are the BDE
>settings.

Just IGNORE this - leave it unassigned. It's merely there to enable you to use an existing idapi32.cfg to set up the connection, if you have an alias defined. IMO, it is more trouble than it is worth.

>Thanks for your help, much appreciated, I really need to start with the
>basics, so will do the IBO tutorial, then build osmething very simple to
>begin with. Looks like using IBO is so much connection orientated.

Using IBO is certainly *data* oriented. But there are two mindsets to deal with here. The IBOQuery which you are using is based on the native Delphi architecture, which provides a generic connection layer to flatten out the differences between desktop (file-based) databases and client/server systems. The UI data-aware controls reflect this presumption of "the lowest common denominator" and these controls drive the data.

"Native IBO" - the TIB_* components, TIB_Datasource and the TIB_* controls - have a quite different perspective. These data-aware controls are driven by the attributes and modes of the datasets. Hence, there is a lot of encapsulated behaviour in these controls that you don't get with the TIBO* and VCL controls combination.

In this sense you are in "double jeopardy" being both a newbie Delphi user and a newbie IBO user. It's hard to say how to advise you. Should you learn how it's done in the VCL so that you can understand just _how_ much better TIB_* is for Firebird/InterBase? Or should you go straight to TIB_* and bypass the TDataset architecture altogether?

Native IBO doesn't use persistent field objects at all. Instead, it works with TIB_Column objects, which are functionally equivalent but incorporate an enormous amount of encapsulation of the information that the server provides about the stored data.

Those who have been used to the BDE techniques sometimes have a lot of trouble adapting to the native IBO techniques. You are so far fairly uncontaminated, I think! I wonder whether Lester might have some advice on this matter!

Regards,
Helen