Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Repairing in a split db environment 1

Status
Not open for further replies.

Pack10

Programmer
Feb 3, 2010
495
US
I have a split db which is suddenly getting
Some corruption. For compacting and repair do I
Have to repair each desktop version or just the
Backed. Also does anyone have experience
Battling error 3049???
Thanks
 
IMO the front end should always compact on close. No reason not to.
 
Ok but I should not compact on close for the back end right
 
I thought that compact on close was a no no
 
the backend never gets opened so it cant compact on close although it should. I use the following function to backup and compact my backends located on another server. The table backend paths are stored on a table

Code:
Public Function CompactBackEndTables(TableName As String) As Boolean
    On Error GoTo Err_Compact

    Dim BackEnd As String
    Dim db As DAO.Database
    Dim rs As DAO.Recordset

    Set db = CurrentDb()
    Set rs = db.OpenRecordset(TableName, dbOpenDynaset)

    rs.MoveLast
    rs.MoveFirst

    Do Until rs.EOF
        With rs
            'Backend full path
            BackEnd = rs!BackendPath
            'Compact the Back-End database to a temp file.
            DBEngine.CompactDatabase BackEnd, BackEnd & "Temp.mdb"
            'Delete the previous backup file if it exists.
            If Dir(BackEnd & ".bak") <> "" Then
                Kill BackEnd & ".bak"
            End If
            'Rename the current database as backup and rename the temp file to
            'the original file name.
            Name BackEnd As BackEnd & ".bak"
            Name BackEnd & "Temp.mdb" As BackEnd
        End With
        rs.MoveNext
    Loop
    CompactBackEndTables = True
Exit_Compact:
    Exit Function
Err_Compact:
    MsgBox Err.Description
    Resume Exit_Compact
End Function

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work
 
The error condition my manager was experiencing
3049 is now gone with compact on close for the front
End. Thanks again.
 
Please search / review the deployment of split dbs. In general, their should be a master FE on a server. Client FE's should check the file dates match and, when not download the server ver to their local systems.. Keeping the server ver compacted (when changes are made) assures the clien FE's will be the correct versions and avoid corruption.

Having the corruption occur at all woould seem to indicate other (probably more serious) problems. Often this comes from collissions in editing data. Compacting simply masks the issue.



MichaelRed


 
I have the exact setup you describe.
We were getting 3049 on a simple record add routine plain
Vanilla .addnew routine. I write errors to a table so I
Know where they are happening. Hard to imagine
That routine causes a problem.
 
it may be a corrupt form you might want to create a new db and import all of the objects into it. I have noted this sometimes occurs when you edit code with the form in form view.

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work
 
Howdy MazeWorX . . .

Out of curiosity ... what does a typical value for [blue]BackEnd[/blue] look like in your table?

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue] [thumbsup2]
Also faq181-2886 [blue]Worthy Reading![/blue] [thumbsup2]
 
The full path including file name. This routine i use in an Admin db that I control however you could modify the path for

Code:
BackEnd = CurrentProject.Path & "\YourDatabaseName.mdb"
or BackEnd = CurrentProject.Path & rs!BackendPath

if you not sure of the actual location of the db to compact and assuming its in the same folder location. I actually have both. Really I should of posted the latter. I should of also note this is used to compact approx 20 backend dbs so the table makes for easy edits if the paths change

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work
 
MazeWorX . . .

If [blue]BackEnd [blue] is indeed a [blue]full path & filename[/blue], then my concern is in purple below:
Code:
[blue]DBEngine.CompactDatabase BackEnd, [purple][b]BackEnd & "Temp.mdb"[/b][/purple][/blue]
Example: BackEnd = "C:\Database\AnyFile.mdb" results in [purple]"C:\Database\AnyFile.mdb"Temp.mdb"[/purple] ... am I missing something? ...

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue] [thumbsup2]
Also faq181-2886 [blue]Worthy Reading![/blue] [thumbsup2]
 
Woops ...

Thats [purple]"C:\Database\AnyFile.mdbTemp.mdb"[/purple]

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue] [thumbsup2]
Also faq181-2886 [blue]Worthy Reading![/blue] [thumbsup2]
 
Yep your not missing anything :)

'MyDatabase.mdb' gets compacted creating a second copy of the db. The compacted version is named 'MyDatabase.mdbTemp.mdb'. The Original copy becomes 'MyDatabase.bak' to serve as a backup. After we have done this we rename the compacted version 'MyDatabase.mdbTemp.mdb' to 'MyDatabase.mdb'


HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work" <<Edison>>
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top