Lester Caine wrote:

>THAT is probably why I was suggesting on a previous thread that a simple
>'one size fits all' solution is probably of little use. This is an area
>where processing the results of the search is as important as the search
>itself, so hooks to provide further processing of the 'result set' are
>important. As Jim has already said - a found/not-found result is only
>half of the problem.
>
>

There are a couple of curious things in Connection.h in the Vulcan
IscDbc module (almost certainly also in the same file in the ODBC IscDbc
modules):

class Statement
{
public:
...
virtual ResultList* search (const char *searchString) = 0;
...
};

and

class ResultList
{
public:
virtual const char* getTableName() = 0;
virtual double getScore() = 0;
virtual int getCount() = 0;
virtual ResultSet* fetchRecord() = 0;
virtual bool next() = 0;
virtual void close() = 0;
virtual void addRef() = 0;
virtual int release() = 0;
virtual int objectVersion() = 0;
};

that may give some hints about how the Netfrastructure search API may work.





[Non-text portions of this message have been removed]