Slow startup Access 2003 with VSS SourceSafe

[Mourad]

After installing SourceSafe integration with Access 2003, th database
startup became very slow. My database is big, more than 10,000 objects
or so. It seems Access/VSS attempts to refresh the Source Control
status (the little lock icon next to each object), and it takes long
time.

Is there a way to disable this update process at start up?

Any work around to get the database starts as fast as it used to be
before the integration?

If there is no way, then anyone recommend an alternative to VSS?

Thanks for reading.

Mourad

 

[Paul Shapiro]

That's a lot of objects for an Access db. The only immediate suggestion is
to make sure the VSS data folder on the server is excluded from anti-virus
checking on both the server and the workstation. Access will indeed refresh
source control status when you open the db and I don't know any way to
disable that.

 

[Mourad]

Thanks Paul, for such a clear answer,

I was thinking to creat an add-in that re-implement the integration
provided by Microsoft, so I can skip the status update, or make it on
demand as opposed to start up, and provide the main actions, check-in,
check-out, ..etc.
Do you know of any VSS interface that I can implement? or what is the
best approach to do this?

Thanks,

Mourad

 

[Guest]

I suggest splitting the mdb up into libraries for a start, and
then dumping source control integration... Once you have
broken the mdb up into libraries, you will no longer be able
to call forms and reports directly (MS broke the work-around
that allowed you to do that), so you will have to implement
function stubs in each library to open library forms and reports.

Library forms and reports refer to tables and queries in the
library mdb, so you will have to create links in each of the
library mdbs. Your DAO code will have to use CodeDB
instead of CurrentDB. Access DoCmd and DLookup actions
refer to tables and queries in CurrentDB, so you will have to
create links in the shell MDB as well (or shift away from
DoCmd actions)

Once you have broken your large MDB into library MDBs,
you can check the library MDBs into VSS as binary objects,
allowing you work independently on sections of your code,
without using Access/VSS integration.

Source code integration uses the SaveAsText/LoadFromText
interface on the Access side. There are some limitations you
may notice. Most important, you can't use "Me.myfield" to refer
to a field in a bound recordset of a form - you must re-write
that as "Me!myfield" or create a bound control with the same
name.

If you want to use source control integration...the VSS addin
is slow, but it also used to break large databases. I wonder
if it is reliable now? Also, it uses the VSS COM interface,
which locks you out so you can't easily do any of the normal
VSS things like viewing code differences. VSS also has a
normal text interface, but Access doesn't use it.

You could try to load your own Access Add-in (like a library
MDB) to handle integration, but since MS does not us Access
Add-in's for their own code any more I can only hope that does
what you want (the code interface is broken but the menu interface
was still ok last I checked). Or you would have to try writing
a COM add-in instead - there are examples on the web somewhere.

As far as I know, no one has released a good replacement
add-in for VSS integration. You can use other source control
systems instead of VSS, but as far as I know, they use the
same Access add-in, and would have the same problems with
start-time, but I've never had the opportunity to try it.

(david)