Helen,

Thanks for the quick reply. My apolgies, I think I have confused you.
I used ISQL with the script to create the FB database and then tried
to connect to the empty table to create a VFP view.

<snip>

> Use Firebird's own ODBC driver.

I did, same result.

<snip>

> The code you supplied doesn't "build a view". Firebird supports

several

> table types, of which TABLE and VIEW are two. TABLE is a physical
> structure that stores data; VIEW is a logical definition that stores a
> compiled SELECT specification on one or more tables, that delivers

output

> as though the structure were a table itself, i.e. it is one form of

what's

> known as "virtual tables".

Yes, I know about tables and views and the differences between them,
the advantages and so on and I know that the script created a table,
I've confused you again by using a VFP term, sorry. I was trying to
create a VFP view on the FB table. This works if you create the VFP
view manually, but not if you use the VFP view designer. Another VFP
user has suggested a solution which I will try.

<snip>

> It should be reasonably OK (in a limited sense) if you use the

correct ODBC

> driver. I'd be especially concerned to make sure that any databases

you

> create are dialect 3 databases, and that the ODBC datasource is set

up to

> connect as a dialect 3 client -- unless you just want to "mess

about", that

> is. A dialect 1 database is just a mostly-compatible InterBase 5
> database; it has different data types, different data structure

rules for

> number types; and it doesn't support the numerous language

enhancements

> that Firebird has.

More confusion, sorry. The database, tables and other contructs will
be created using ISQL and scripts, and VFP used to access and
manipulate the data.

> Firebird is independent of any development language; however, you will
> encounter some "linguistic" limitations by using a language that was
> designed for a low-end, file-based data management system. You need to
> take account of transactions - which you can deal with by the

appropriate

> ODBC driver settings (get the oil on this by joining the
> firebird-odbc-devel mail list) and live with the fairly crippled

sort of

> interface that is necessary to drag Firebird down to the level of

database

> support that the VFP language is capable of.

Well, I would say that you don't use VFP much :) It has a great deal
of built in support for 'real' databases but not if you want API
access to the database. ODBC and ADO are the 'Microsoft recognised'
way of getting data into and out of 'real' databases. It has
transaction support in it's own database files and uses SQL pass
though to use transactions in the 'real' databases, can be used for CS
aplications and if used properly, scales well.

I would venture to suggest that you can take addvantage of most of the
features of 'real' databases from within VFP, at least it seems that
way when talking to fellow developers who regularly use SQL Server,
Oracale, DB2 and the like. We just don't have the possibility to use a
database that requires any form of regular administration as required
by the above databases, we need a set-it-up-and-forget-it system which
Firebird seems to provide.

> I'd guess that you will reach a point where you will recognise that

these

> limitations are standing in the way of doing an effective upscaling.

Unlikely, see above.

While

> using Firebird as the back-end will offer improvements in robustness

and

> (with good object structures and optimal SQL) improved performance,

you'll

> be denying yourself the real benefits of a properly separated

client/server

> architecture.
>
> ./hb

Again, unlikely for the same reasons. Besides, many of my fellow VFP
developers create professional client/server applications using VFP. I
just have a problem creating VFP views using the VFP view designer
when using FB as the datebase.

MA