At 11:55 AM 12/09/2009, you wrote:

> > I have exactly the same issue - using 4.8.6 IB OBjects - am setting
> > the 'SchemaCacheDir' to 'c:\temp' - and have tried various other
> > folders on different drives - the sub-folder (with the FBD filename)
> > is never created.
> >
> > Tried setting the 'SchemaCacheDir' inside the coding, just before the
> > open or just after the open of the connection - still nothing.
> >
> > I would really appreciate any assistance, as my application has been
> > deployed over a WAN and the performance (especially initial database
> > connect) is terrible.... and the whipping boys are out to get me!
> >
> > Best regards
> > Brian Culverwell
> >
> >
>

>Thanks for the reply - does not really help me though - you are describing a working situation using the things I have tried - but it just does NOT create the sub-folder at all.

No, it does NOT create the sub-folder. As I and others have already told you, schema caching will be just a no-op if the sub-folder doesn't already exist. You have to create it, either manually, or (with appropriate permissions) using a filesystem call from your installer (or, maybe, your application...but on Vista, it's not necessarily going to be written to an appointed place but to some location in the user's own filespace).

>I am running on vista - but using a public folder (c:\temp) so permissions are not an issue.

It's not the immediate problem, though. Your expectation that IBO creates the appointed sub-folder is the immediate problem.

>Also as an aside, does anyone know if using the schema cache (from 2nd connection onwards) improves the speed of the actual connect? And by how much?

The purpose of the schema cache is to reduce unnecessary network traffic at connection time. "How much" is impossible to say, since network performance for a given client depends on a lot of factors, most of them external. However, if you are writing applications that start with multiple open datasets, clients should notice a difference if they are on a slow network connection. It's not good practice to write client/server apps that way, natch. OTOH, if you are frequently changing metadata in your database, you'll have the added overhead of clients needing to refresh the SchemaCache at connection.

Don't overlook the possibility that your connection-time woes are related to something else, such as locating databases in shared folders; not disabling System Restore and/or Shadow Copy on the volume where databases are located; waiting for wrongly-configured firewall software to do its stuff; and so on. Not attending to these details can also cause corruption in some conditions, as well.

Helen