I designed it that way. I was thinking that at the end of the day, eventually only one person will be in the system and when he/she quits it will trigger the pack. If your worried about someone reading the deleted data you could add a statement to replace the connection's password with blank data.

PROCEDURE dbc_BeforeDeleteConnection(cConnectionName)
*Just before a connection is deleted. Return .F. to prevent item from being deleted.
DBSETPROP(cConnectionName,"CONNECTION","PassWord","")
ENDPROC


>The problem here is that we have 100s of users at some sites so we rarely get the opportunity to open the DBC exclusively.
>
>Cheers
>Mike
>
>>If you open the database and then "MODI PROC" and add the code below, then turn on the database events (MODI DATA -> RIGHT-CLICK ->PROPERTIES), the code below should work...except that I think there's a bug in VFP 8 sp1 (see thread #836767) that essentially makes this code inop.
>>
>>PROCEDURE dbc_CloseData(cDatabaseName, lAll)
>>*Before DBC is closed. Return .F. to prevent DBC from being closed.
>>IF pPACKDATABASE(cDatabaseName)
>> =MESSAGEBOX('PACKED') &&FOR TESTING
>>ELSE
>> =MESSAGEBOX('NOT PACKED') &&FOR TESTING
>>ENDIF
>>ENDPROC
>>
>>PROCEDURE pPACKDATABASE
>>LPARAMETERS cDatabaseName
>>LOCAL is_error, lcERR_Proc
>>STORE ON('error') TO lcERR_Proc
>>ON ERROR is_error=.T.
>>OPEN DATABASE (cDatabaseName) EXCL
>>IF NOT is_error
>> PACK DATA
>>ENDIF
>>ON ERROR &lcERR_Proc
>>RETURN(NOT is_error)
>>
>>>>One way would be to encrypt the connection string and save it to the registry. Then, when you need it, just read it from the registry and de-crypt.
>>>>
>>>>>We have an application that needs to connect to an ODBC datasource using a DBC connection which is shared by DBC remote views. We don't want to store the ODBC password in the DBC as this would allow users with read only access to the DBC to see the password.
>>>>>
>>>>>We have been holding an encrypted version of the password in a file and the when the application connects to the database we modify the DBC connection to put in the password, make the connection and then modify the DBC connection again to blank out the password.
>>>>>
>>>>>This approach has 2 problems:-
>>>>>
>>>>>1. It creates deleted records in the dbc which lead to file bloat.
>>>>>2. Some users have discovered they can open the DBC as a text file and see the deleted records and therefore the password!
>>>>>
>>>>>Does anyone have a better means of making a remote connection but keeping the password secure?
>>>>>
>>>>>TIA
>>>This is effectively what we do now - the problem lies in having to save the unencrypted password into the connection in the DBC at the time of opening so that we can share the connection in remote views.
>>>
>>>When the connection in the DBC is updated in this way it creates a new record everytime with the old sitting as a deleted record in the dbc.