|
Datenbank neu erstellen mit VBA
|
| Autor |
Nachricht |
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
01. Feb 2010, 15:24
Rufname:
|
|
| Version: Office 2007 |
|
Hallo zusammen,
wenn man einige Zeit an einer Datenbank herumprogrammiert, diese zwischendurch vielleicht auch schon das ein oder andere Mal abgestürzt ist usw., dann kann es schnell dazu kommen, daß die Datenbankdatei sozusagen "im Hintergrund" eine Menge Binärmüll ansammelt, der in der Praxis bereits dazu geführt hat, daß ein Access Frontend willkürliche und nicht nachvollziehbare Abstürze produziert hat, die nichts mit fehlerhaftem Code oder Einstellungen usw. zu tun hatten. Der Binärmüll kann durch "Compact and repair" nicht "entsorgt" werden.
Wie so oft gelesen, erstellt man sich dann meistens eine neue Datenbankdatei und fängt an, alles aus der defekten Datenbank zu importieren und die Einstellungen entsprechend anzupassen.
Der Weg ist an sich OK, jedoch besteht theoretisch die Gefahr, mit dem direkten Importieren auch fehlerhafte Hintergrunddaten mit zu importieren, so daß die neue Datenbank auch wieder Fehler enthält. Der einzig wirklich sichere Weg ist das Verwenden der nicht dokumentierten Funktionen Application.SaveAsText und Application.LoadFromText, um alle Objekte als reine ASCII-Daten zu exportieren und in der neuen Datenbank wieder zu importieren.
Das funktioniert sehr gut und die Datenbank wird im Regelfall auch um einiges kleiner. Lediglich ist es sehr mühsam, alle Objekte auf diese Weise zu importieren und exportieren. Daher hier ein anderer Weg (der allerdings in der Regel nur funktioniert, wenn die Ursprungsdatei noch normal startbar ist).
Das folgende Modul einfach in die Ursprungsdatenbank unter einem beliebigen Modulnamen einbauen und "procRecreate" im Direktfenster von VBA aufrufen.
Das Modul ist für die Kopie eines Access 2007 Projektes (ADP) geschrieben, sollte aber mit ein paar Anpassungen auch mit einer Access Datenbank funktionieren. Es werden nur Makros, Module, Formulare und Reporte in die neue Datenbank kopiert, keinerlei Daten oder Queries (da es diese in einer ADP nicht gibt und es keinen Sinn machen würde, sie vom SQL Server kopieren zu wollen). Diese Objekte müßten für eine normale Access Datenbank also selbst hinzugefügt werden.
| Code: | Option Compare Database
Option Explicit
Public Sub procRecreate()
Dim strFile As String
Dim strConnection As String
Dim objAccess As New Access.Application
strFile = InputBox("Filename: ", "Select:")
If UCase(Right(strFile, 4)) = ".ADP" Then
strFile = Left(strFile, Len(strFile) - 4)
End If
strConnection = Application.CurrentProject.Connection.ConnectionString
Debug.Print "---- Create new database with current connection string ----"
Application.CreateAccessProject CurrentProject.Path & "\" & strFile _
& ".adp", strConnection
Set objAccess = CreateObject("Access.Application")
objAccess.OpenAccessProject CurrentProject.Path & "\" & strFile & ".adp" _
, True
Debug.Print "---- Save current references ----"
procRCSaveReferences
Debug.Print "---- Save current objects ----"
procRCSaveAllAsText
Debug.Print "---- Load objects into new database ----"
procRCLoadAllFromText objAccess
Debug.Print "---- Load references into new database ----"
procRCLoadReferences objAccess
Debug.Print "---- Set options in the new database like in the current ----"
procRCSetOptions objAccess
objAccess.CloseCurrentDatabase
Set objAccess = Nothing
End Sub
Private Sub procRCSaveAllAsText()
Dim obj As Object
Dim strModuleLine As String
Dim strPath As String
strPath = CurrentProject.Path & "\"
On Error Resume Next
Kill strPath & "Forms"
Kill strPath & "Modules"
Kill strPath & "Macros"
Kill strPath & "Reports"
RmDir strPath & "Forms"
RmDir strPath & "Modules"
RmDir strPath & "Macros"
RmDir strPath & "Reports"
MkDir strPath & "Forms"
MkDir strPath & "Modules"
MkDir strPath & "Macros"
MkDir strPath & "Reports"
On Error GoTo 0
Debug.Print "Forms...";
For Each obj In CurrentProject.AllForms
Application.SaveAsText acForm, obj.Name _
, CurrentProject.Path & "\Forms\" & obj.Name _
& ".frm"
Debug.Print ".";
Next obj
Debug.Print
Debug.Print "Macros...";
For Each obj In CurrentProject.AllMacros
Application.SaveAsText acMacro, obj.Name _
, CurrentProject.Path & "\Macros\" & obj.Name _
& ".mac"
Debug.Print ".";
Next obj
Debug.Print
Debug.Print "Modules...";
For Each obj In CurrentProject.AllModules
Application.SaveAsText acModule, obj.Name _
, CurrentProject.Path & "\Modules\" & obj.Name _
& ".mod"
Open CurrentProject.Path & "\Modules\" & obj.Name & ".mod" For _
Input As #1
Open CurrentProject.Path & "\Modules\" & obj.Name & ".bas" For _
Output As #2
' Bei "SaveAsText" wird die folgende Zeile nicht mit gespeichert,
' diese wird aber für den Import benötigt, damit Access automatisch
' den richtigen Modulnamen verwendet. Daher wird die Zeile hier
' ergänzt.
Print #2, "Attribute VB_Name = """ & obj.Name & """"
Do
Line Input #1, strModuleLine
Print #2, strModuleLine
Loop Until EOF(1)
Close #1
Close #2
Kill CurrentProject.Path & "\Modules\" & obj.Name & ".mod"
Debug.Print ".";
Next obj
Debug.Print
Debug.Print "Reports...";
For Each obj In CurrentProject.AllReports
Application.SaveAsText acReport, obj.Name _
, CurrentProject.Path & "\Reports\" & obj.Name _
& ".rpt"
Debug.Print ".";
Next obj
Debug.Print
End Sub
Private Sub procRCLoadAllFromText(ByRef objAccess As Access.Application)
Dim strFile As String
Debug.Print "Forms...";
strFile = Dir(CurrentProject.Path & "\Forms\*.*")
Do While strFile <> ""
objAccess.Application.LoadFromText acForm _
, Left(strFile, Len(strFile) - 4) _
, CurrentProject.Path & "\Forms\" _
& strFile
strFile = Dir()
Debug.Print ".";
Loop
Debug.Print
Debug.Print "Macros...";
strFile = Dir(CurrentProject.Path & "\Macros\*.*")
Do While strFile <> ""
objAccess.Application.LoadFromText acMacro _
, Left(strFile, Len(strFile) - 4) _
, CurrentProject.Path & "\Macros\" _
& strFile
strFile = Dir()
Debug.Print ".";
Loop
Debug.Print
Debug.Print "Modules...";
strFile = Dir(CurrentProject.Path & "\Modules\*.*")
Do While strFile <> ""
objAccess.Application.LoadFromText acModule _
, Left(strFile, Len(strFile) - 4) _
, CurrentProject.Path & "\Modules\" _
& strFile
strFile = Dir()
Debug.Print ".";
Loop
Debug.Print
Debug.Print "Reports...";
strFile = Dir(CurrentProject.Path & "\Reports\*.*")
Do While strFile <> ""
objAccess.Application.LoadFromText acReport _
, Left(strFile, Len(strFile) - 4) _
, CurrentProject.Path & "\Reports\" _
& strFile
strFile = Dir()
Debug.Print ".";
Loop
Debug.Print
End Sub
Private Sub procRCSaveReferences(Optional strRefFileName As Variant)
On Error GoTo SaveReferences_Error
Dim objRef As Access.Reference
Dim f As Integer
If IsMissing(strRefFileName) Then
strRefFileName = CurrentProject.Path & "\References_" _
& Left(CurrentProject.Name _
, Len(CurrentProject.Name) - 4) & ".txt"
End If
f = FreeFile
Open strRefFileName For Output As #f
For Each objRef In Access.References
'If Not objRef.IsBroken Then Print #f, objRef.Name & ":" & vbTab _
& vbTab & objRef.FullPath
If Not objRef.IsBroken Then Print #f, objRef.FullPath
Next objRef
Close #f
SaveReferences_Exit:
Exit Sub
SaveReferences_Error:
MsgBox Err.Description
Resume SaveReferences_Exit
End Sub
Private Sub procRCLoadReferences(ByRef objAccess As Access.Application)
Dim f As Integer
Dim strLine As String
With objAccess
' Access trägt standardmäßig ADODB 2.5 ein, daher erst Remove
.Application.References.Remove .Application.References.Item("ADODB")
f = FreeFile
Open CurrentProject.Path & "\References_" _
& Left(CurrentProject.Name, Len(CurrentProject.Name) - 4) _
& ".txt" For Input As #f
On Error Resume Next
Do While Not EOF(f)
Line Input #f, strLine
.Application.References.AddFromFile strLine
Loop
Close #f
End With
End Sub
Private Sub procRCSetOptions(ByRef objAccess As Access.Application)
Dim strOptions(1 To 14) As String
Dim varValue As Variant
Dim objProperty As AccessObjectProperty
Dim strPropertyName As String
Dim i As Long
strOptions(1) = "Auto Compact"
strOptions(2) = "Remove Personal Information"
strOptions(3) = "Themed Form Controls"
strOptions(4) = "DesignWithData"
strOptions(5) = "CheckTruncatedNumFields"
strOptions(6) = "Picture Property Storage Format"
strOptions(7) = "Track Name AutoCorrect Info"
strOptions(8) = "Perform Name AutoCorrect"
strOptions(9) = "Log Name AutoCorrect Changes"
strOptions(10) = "Show Values in Indexed"
strOptions(11) = "Show Values in Non-Indexed"
strOptions(12) = "Show Values in Remote"
strOptions(13) = "Show Values in Snapshot"
strOptions(14) = "Show Values in Server"
' Die Option läßt sich nicht setzen, wenn der Wert außerhalb des
' Integer-Bereichs liegt.
' Die GUI läßt hier einen größeren Wert zu.
'strOptions(15) = "Show Values Limit"
With objAccess
For i = LBound(strOptions) To UBound(strOptions)
varValue = Application.GetOption(strOptions(i))
.SetOption strOptions(i), varValue
Next i
On Error Resume Next
For Each objProperty In CurrentProject.Properties
strPropertyName = ""
strPropertyName _
= .CurrentProject.Properties(objProperty.Name).Name
If strPropertyName <> objProperty.Name Then
.CurrentProject.Properties.Add objProperty.Name _
, objProperty.Value
Else
.CurrentProject.Properties(objProperty.Name) _
= objProperty.Value
End If
Next objProperty
End With
End Sub |
Es wird nach dem Dateinamen für eine neue ADP-Datenbank gefragt, unter diesem Namen wird dann die neue ADP im Verzeichnis der aktuellen Datenbank angelegt. Dann werden alle o.g. Objekte in einzelne Unterordner exportiert und in die neue Datenbank importiert. Zuletzt werden die Optionen aus der aktuellen Datenbank ausgelesen und in die neue importiert.
Interessant ist dabei besonders die folgende Einstellung:
| Code: | | ?CurrentProject.Properties("DocUICustomization") |
Man erhält (sofern man die Quick Access Toolbar verändert hat) eine kleine XML-Auflistung, in der alle selbst eingestellten Icons der Quick Access Toolbar definiert werden. Kopiert man diese Einstellung in eine neue Datenbank, hat man auch die Quick Access Toolbar wieder wie im Original. Im Gegensatz zu vielen Tips im Internet ist es daher nicht notwendig, erst mühsam ein Ribbon zu erstellen und in Access zu laden - es genügt diese kleine Eigenschaft zu kopieren.
Leider funktioniert der Trick nicht mit "echten" Ribbons, dafür gibt es keine andere Methode also die Load-Methode für Ribbons.
Die neue Datenbank sollte nach dieser Prozedur kleiner sein, frei von Binärmüll und mit überwiegend allen wichtigen Einstellungen aus der alten Datenbank. Das ganze läßt sich wahrscheinlich noch verfeinern und verbessern, aber für mich tut's das erstmal und spart mir eine Menge Zeit.
Viel Spaß damit...
Christian
|
|
astern
Datenmodell-Missionar
Verfasst am:
08. Feb 2010, 14:50
Rufname: Andreas
Wohnort: Rastede
|
| |
| Version: Office 2007 |
|
Hallo,
und Danke für Deinen Code! Ich finde ihn außerordentlich nützlich, weil ich mich schon etliche Male von Hand durch die ganze Export/Import-Prozedur gequält habe!
Ich kenne mich allerdings mit Access-Projekten überhaupt nicht aus und wollte den Code jetzt mal für accdb-Datenbanken modifizieren.
(1) Den Beginn der Prozedur procRecreate habe ich so modifiziert:
| Code: | strFile = InputBox("Name der neuen DB (OHNE Dateitypendung!): ")
Debug.Print "---- Create new database ----"
Set objAccess = CreateObject("Access.Application")
objAccess.NewCurrentDatabase CurrentProject.Path & "\" & strFile & ".accdb", _
acNewDatabaseFormatAccess2007 |
Das funktioniert auch - aber ob es wirklich richtig ist, wollte ich Dich hiermit fragen.
(2) Ich möchte auch Abfragen exportieren/importieren. Das hat aber mit
| Code: | | For Each obj In CurrentProject.AllQueries |
nicht funktioniert. Darum habe ich es so verändert:
| Code: | Debug.Print "Queries...";
For Each obj In CurrentData.AllQueries
Application.SaveAsText acQuery, obj.Name _
, CurrentProject.Path & "\Queries\" & obj.Name _
& ".qry"
Debug.Print ".";
Next obj
Debug.Print |
Auch hier wieder:
Das funktioniert auch - aber ob es wirklich richtig ist, wollte ich Dich hiermit fragen.
(3) Die Zeile
| Code: | | .Application.References.Remove .Application.References.Item("ADODB") |
in der Prozedur procRCLoadReferences verursacht bei mir den Fehler "Index außerhalb des gültigen Bereiches". Ich habe sie einfach auskommentiert - und:
Das funktioniert auch - aber ob es wirklich richtig ist, wollte ich Dich hiermit fragen.
(4) Was kann ich mit den Tabellen machen? Ich würde sie gerne wahlweise mit oder ohne Daten exportieren+importieren. Geht das auch mit dieser Technik?
(5) Das mit den Optionen habe ich auch noch nicht kapiert. Du schreibst: "Set options in the new database like in the current" - dann sind die Optionen in der entspr. Prozedur aber hardcodiert - also nicht "like in the current"!??
MfG
A*
_________________
1. Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!
| Beschreibung: |
|
Download |
| Dateiname: |
ASCII-Export-Import-v01.zip |
| Dateigröße: |
201.15 KB |
| Heruntergeladen: |
32 mal |
|
|
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
08. Feb 2010, 23:50
Rufname:
|
|
| Version: Office 2007 |
|
Hallo,
finde ich gut, daß Du das für Accdb umgesetzt hast, mir fehlt im Moment die Zeit dazu und beruflich arbeite ich momentan nur noch mit Projekten.
Um die Fragen zu beantworten: Wenn es klappt, dann ist es auch richtig...
In Access Projekten müssen manche Objekte etwas anders angesprochen werden. Trotzdem gibt es auch manche, die man in beiden benutzen kann wie etwa "CurrentProject". Aber auch wiederum nicht alles davon kann man in ACCDB benutzen.
Also wenn Du nach Ausführung festgestellt hast, daß alles in der Zieldatenbank drin ist, dann war es in Ordnung.
Für Tabellen habe ich mir die Arbeit nicht gemacht, weil es die, wie gesagt, in Access Projekten nicht gibt (da sie alle auf dem SQL Server stehen und von daher kein Recreate notwendig ist).
In ACCDB sind die Tabellen aber Bestandteil der Datei, daher macht es durchaus Sinn, sie auch neu zu erstellen. Leider ist damit aber auch erhebliche Mehrarbeit inbegriffen, denn nur die Struktur und die Daten zu kopieren, genügt nicht. Um die Datei richtig neu aufzubauen, müßten auch die Indizes neu erstellt und die Beziehungen zwischen den Tabellen für die referentielle Integrität neu aufgebaut werden. Der notwendige Code dazu würde sicher relativ viel aufwendiger werden als dieses kleine Tool.
Bei Queries ist es da schon einfacher, da sie im Prinzip nur aus einem SQL-Befehl bestehen. Im Prinzip. Aber Access kann ja auch Indizes auf Queries vergeben (wenn auch sehr selten benutzt) und außerdem externe Tabellen verlinken, womit das alles schon wieder etwas komplizierter wird.
Mit SaveAsText eine Query zu speichern, sollte aber in den meisten Fällen genügen (so es denn geht, hab's noch nicht ausprobiert, in Access Projekten geht's nicht).
Mit den Access Optionen ist es etwas komplizierter. Es mag auf den ersten Blick so aussehen wie hart codiert, ist es aber tatsächlich nicht. Ich hatte zunächst den Weg über "SetOption" probiert und damit begonnen, die Namen aus der Hilfe in Strings zu codieren und dann "abzuklappern". Aber bei "strOption(15)" mit "Show Values Limit" habe ich dann festgestellt, daß die Optionen nicht korrekt übernommen werden. In Access hatte ich "1000000" eingestellt, was die GUI auch ohne zu meckern übernommen hat. Bei näherer Analyse der internen Speicherung ergab sich aber, daß dieser Wert gar nicht verwendet werden kann (und daß man eigentlich einfach nur "0" eingeben muß, um immer alle Datensätze zu bekommen, betrifft aber nur Projekte), der Wert wird also auch mit SetOption in der Zieldatenbank nicht angenommen. Aber er wird auch nicht beanstandet.
Damit fand ich diesen Weg für nicht akzeptabel, denn wenn die Optionen dann doch teilweise wieder nicht stimmen, macht es keinen Sinn.
Daher bin ich dann den anderen Weg über "CurrentProject.Properties" gegangen, in dieser Auflistung befinden sich tatsächlich alle Optionen, die man auch mit SetOption setzen kann, und damit kann man zuverlässig alle Optionen kopieren. Daher ist der Teil darüber eigentlich nicht mehr notwendig, vorsichtshalber habe ich es aber dringelassen.
Dabei gibt es aber noch eine Falle: Access hat nämlich nicht für alle Optionen ein Name/Wert-Paar, in dem alle Optionen eingetragen sind, sondern nur für die tatsächlich gesetzten Optionen. Aus diesem Grund ist der Trick hier das "On Error Resume Next", indem ich dem strPropertyName erst einen leeren String zuweise und dann versuche, den Optionsnamen zuzuweisen. Wenn hierbei ein Fehler auftritt, wird in die nächste Zeile gesprungen und dann íst der String immer noch leer, entsprechend muß dann die Option in der Zieldatenbank mit "Add" hinzugefügt werden. Ansonsten, wenn es die Option in der Zieldatenbank schon gibt, wird nur der Wert geändert.
So ist es auch mit den Referenzen: Auch das ist eigentlich nur eine Auflistung von Einträgen, entsprechend bedeutet die Fehlermeldung "Index außerhalb des gültigen Bereiches", daß die Referenz in der Zieldatenbank nicht vorhanden ist und entsprechend auch nicht entfernt werden kann. Das ist auch kein Wunder, denn in einer ACCDB wird standardmäßig mit DAO gearbeitet, in einem Projekt dagegen standardmäßig mit ADO. Entsprechend braucht man auch keine ADO-Referenz hinzuzufügen, es sei denn, man möchte sie benutzen oder die gegenwärtige Datenbank verwendet sie.
In neuen Datenbanken für Access 2007 heißt die Referenz nur nicht mehr DAO sondern "Microsoft Office 12 Access database engine Object library" (ja, wer mag sich sowas nur ausdenken....).
Diese wird automatisch erzeugt und ist korrekt, braucht daher auch nicht erneuert zu werden. In Projekten wird aber das 2003-Datenbankformat verwendet, weswegen wohl vermutlich auch der alte ADO 2.5-Link hinzugefügt wird statt dem aktuelleren 2.8.
Was die Tabellen angeht, so kannst Du natürlich auch auf die TableDefs-Auflistung zugreifen, die Struktur damit in der neuen Datenbank anlegen und dann mit SELECT INTO oder INSERT INTO...SELECT die Daten in die neue Datenbank kopieren. Für Indizes und Beziehungen ist da schon etwas mehr Arbeit nötig.
Gruß
Christian
|
|
astern
Datenmodell-Missionar
Verfasst am:
09. Feb 2010, 09:54
Rufname: Andreas
Wohnort: Rastede
|
|
| Version: Office 2007 |
|
Hallo,
und Danke für Deine ausführlichen Erläuterungen! Dann werde ich mal sehen, dass ich das mit den Tabellen und Beziehungen auch noch hinkriege. Noch zwei Fragen:
(1) Was ist mit der auskommentierten Zeile in procRCSaveReferences ("If Not objRef.IsBroken Then ...")? Kann die ganz weg bzw. in welchem Fall braucht man die?
(2) Wenn ich Deine Erklärungen zu den Optionen richtig verstanden habe, dann könnten ja in procRCSetOptions alle Zeilen "strOptions(...) = ..." weg und auch die For-Schleife nach With objAccess!? Richtig? So dass nur noch die For Each-Schleife übrig bleibt?
MfG
A*
PS: Ich habe gerade etwas herumgegoogelt - und: Der Export/Import von Tabellen und Relationen wird wohl nicht so einfach werden. Einen Parameter acTable für die Funktion SaveAsText gibt es zwar - seine Benutzung führt aber zur Fehlermeldung "Das Argument Objekttyp dieser Methode ist ungültig". Und einen Parameter acRelation gibt es erst gar nicht ...
_________________
1. Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!
|
|
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
09. Feb 2010, 19:25
Rufname:
|
|
| Version: Office 2007 |
|
Hallo,
ja, die auskommentierte Zeile kann weg, das ist noch ein Rest aus einer früheren Funktion.
Auch die For-Schleife und die Strings können theoretisch weg, habe es aber noch nicht ausprobiert. Müßte aber ohne genausogut funktionieren.
Das meinte ich: Bei Tabellen mit Beziehungen und Indizes wird es schon eine ganze Ecke aufwendiger. Machbar ist es, aber nicht mit SaveAsText.
Gruß
Christian
|
|
astern
Datenmodell-Missionar
Verfasst am:
10. Feb 2010, 00:18
Rufname: Andreas
Wohnort: Rastede
|
|
| Version: Office 2007 |
|
Hallo!
Ich bin jetzt auf TransferDatabase gestoßen und habe damit auf ziemliche einfache Weise die Tabellen in die neue DB transferiert:
| Code: | For Each objTable In Application.CurrentData.AllTables
If Left(objTable.Name, 4) <> "MSys" Then
Debug.Print objTable.Name;
Debug.Print
DoCmd.TransferDatabase acExport, "Microsoft Access", strFullFileName, _
acTable, objTable.Name, objTable.Name, True
End If
Next objTable |
Würdest Du das nicht machen, weil damit der "Binärmüll" mit in die neue DB übernommen wird? Sollte man auch hier den (wohl sehr viel komplizierteren) Weg über ASCII-Dateien gehen?
Mit TransferDatabase könnte man ja auch alle anderen Objekte auf die neue DB übertragen (Formulare, Abfragen, Makros, ... usw.)
MfG
A*
_________________
1. Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!
|
|
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
10. Feb 2010, 01:23
Rufname:
|
| |
| Version: Office 2007 |
|
Hallo,
TransferDatabase ist der gleiche Vorgang, als ob Du in einer neuen Datenbank zum Beispiel Objekte importierst, was ja auch mit defekten Datenbanken funktioniert. Es wird im Regelfall funktionieren, ich würde es allerdings ohne diese Methode machen, weil ich eben befürchte, daß dabei in der Tat der Binärmüll mitgenommen wird.
Gut Ding will Ausdauer haben...
Gruß
Christian
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen
|
|
|
|
| Verwandte Themen |
| Forum / Themen |
Antworten |
Autor |
Aufrufe |
Letzter Beitrag |
 |
Access Formulare: Ausgabeformular erstellen |
2 |
mc-cain |
203 |
29. Jan 2010, 16:06
Gast  |
|
Access Hilfe: Fragezeichen in Datenbank ersetzen?? |
11 |
NilsL |
308 |
14. Jan 2010, 12:41
MissPh! |
|
Access Tabellen & Abfragen: Accessdatenbank komplett per Skript erstellen |
3 |
joekli |
516 |
20. Aug 2009, 15:46
Bitsqueezer |
|
Access Formulare: Englisch Deutsch Wörterbuch in Access erstellen |
0 |
Basejumper |
416 |
02. Aug 2009, 20:59
Basejumper |
|
Access Programmierung / VBA: Backup in einzelnen Unterordnern erstellen |
6 |
pho |
208 |
08. März 2009, 11:05
pho |
|
Access Tabellen & Abfragen: aus einer 2 stelligen zahl ein Datum erstellen |
17 |
Haag |
505 |
28. Feb 2009, 16:24
Haag |
|
Access Hilfe: Maschinen Datenbank erstellen |
1 |
Gast |
406 |
13. Jun 2008, 09:56
RadiatoR |
|
Access Programmierung / VBA: VBA Code für Datenbank komprimieren und reparieren... !!!! |
7 |
lars.muc |
4677 |
09. Jun 2008, 21:10
Willi Wipp |
|
Access Hilfe: Datenbank auf Netwerk ablegen/ verschiedene Berechtigungen |
2 |
schnacko |
306 |
03. Jun 2008, 14:03
Telechinese |
|
Access Programmierung / VBA: PDF erstellen aber dann Abbrechen drücken gibt Fehler |
2 |
Psus82 |
406 |
27. Feb 2008, 12:53
Psus82 |
|
Access Formulare: MDE Datenbank kann nicht erstellt werden |
3 |
anova |
913 |
26. Okt 2007, 20:09
Gast |
|
Access Programmierung / VBA: Filter aus Suchformular für Bericht erstellen |
1 |
2stupid4this |
610 |
25. März 2007, 04:09
Nouba |
| |
|
