> Yes, it is a query *specification* which is stored for a specific
> purpose. It specifies an output set on whose data you can operate
> as though it were a table.

> Views can be used almost wherever a table is used. You can select
> from
> them (complete with WHERE, GROUP BY, ORDER BY, etc.). In most
> cases, a
> view can be made "updatable", by use of triggers. Updates to data
> in a
> view of course are applied to the underlying tables.
>
> A common use is to isolate one subset of the data in a table, or a
> group of
> related tables, to an appointed user, for just the kind of
> security
> situation you have described.

However I talk of isolating data per each employer, I don't care who in
the firm sees it, however it is important that one employers data, does
not mix with another.
ie both employers will more than likely share employees, however there
is a privacy act which declares that even though the accountant may
have gathered information about the employee from EmployerA, he cannot
use this information to fill in details regarding the employee as an
employee of employerB (if that makes sense).
And this is a very likely case, as I am writing this for contractors of
itinerate workers. So one firm will more then likely handle multiple
employers in the district, and the workers in town during the season
will flick between a number of employers.

> Because a view is a database object, it is subject to privileges,
> just as
> tables and stored procedures are. Did you realise that the only
> users who
> have access to the data in a database without being granted
> specific
> privileges are the SYSDBA and the user which owns the database (if
> this
> user is not SYSDBA)? Lookup Security in the guides. In SQL, look
> up GRANT
> and REVOKE.

This I didn't realise, but sounds like something I need to know more
about.

However, designing a database that is going to get

> metadata updates
> remotely is NOT beginner stuff.

I don't intend on doing metadata updates, I just hate the thought of
designing a database that is render useless too quickly due to not
enough forethought.

> Portable "data files" are not database tables. Fb/IB doesn't
> store data in
> "data files". It does have some mechanisms by which you can make
> external
> files visible to the database engine, as if they were database
> tables.

How then do applications such as MYOB & Quickbooks accomplish there
tasks?
I am not writing accounting software, however surely this software uses
databases? and each 'client' maintains its own copy, easily copied by a
simple copy-and-paste from explorer. Can be opened and viewed at the
accountants, etc.
This is the type of mobility I am going for.
Is IB/FB not designed for this? or is this what you meant by EXTERNAL
FILEs?

> There are several third-party tools available that can convert
> external
> file formats like CSV, et al. into Fb/IB tables. Look at the
> IBPhoenix
> site to find these.

Will do.