Zusammenwirken ACCESS / EXCEL

27/11/2009 - 14:47 von Stefan Ruppel | Report spam
Ich habe letzte Woche schon ganz super geholfen bekommen und jetzt das Thema
recht gut im Griff - naja nicht ganz: Der folgende Code funktioniert in
Access ganz prima zum Auflisten aller Functions/Subs. Aber eben nur in Access
- meine Versuche ihn von EXCEL aus das gleiche verrichten zu lassen
scheitern, ich nehme an, weil es entweder gar nicht geht, oder weil ich
einfach zu dàmlich bin die richtige Verbindung hinzubekommen.

Ich glaube, daß ich die in Datenquelle bezeichnete DB zwar öffne, aber die
darin befindlichen Komponenten nicht abfrage (weil keine Verbindung
besteht?). War dagegen noch eine DB offen wird diese ausgewertet, nicht aber
diejenige, die ich eigentlich will. Was mach ich falsch? Merci an alle!
Stefan Ruppel

Sub Schaltflàche14_KlickenSieAuf()
Dim DATEN_QUELLE As String
Dim Datenbank As Database
DATEN_QUELLE = Worksheets("Programmseite").Range("c4").Value
Set Datenbank = OpenDatabase(DATEN_QUELLE)
Dim myProject As VBProject
Dim myComponent As VBComponent

'Datenbank öffnen
'alle vorhandenen Makros/Functions einlesen einlesen
Dim strNames As Variant, strDocNames As String
Dim strFile() As String
Dim iCount As Integer
Dim strProc As String

' Alle Projekte durchlaufen
For Each myProject In VBE.VBProjects
strNames = ""
' Nur ungeschützte berücksichtigen
If myProject.Protection = vbext_pp_none Then
On Error Resume Next
If myProject.VBComponents.Count > 1 Then
strFile() = Split(myProject.Filename, "\")
strNames = strNames & myProject.name & " (" & _
strFile(UBound(strFile())) & ")" & vbCrLf
On Error GoTo 0
' Alle Module durchlaufen
For Each myComponent In myProject.VBComponents
With myComponent
' Modul-Typ ermitteln
If .Type = vbext_ct_StdModule Then
strNames = strNames & vbTab & .name & vbCrLf
ElseIf .Type = vbext_ct_ClassModule Then
ElseIf .Type = vbext_ct_MSForm Then
ElseIf .Type = vbext_ct_Document Then
End If
' Declaration auslesen
If .CodeModule.CountOfDeclarationLines > 0 Then
For iCount = 1 To .CodeModule.CountOfDeclarationLines
If .CodeModule.Lines(iCount, 1) <> "" Then
Exit For
End If
Next iCount
End If
' Prozeduren auslesen
strProc = ""
For iCount = 1 To .CodeModule.CountOfLines
If .CodeModule.ProcOfLine(iCount, vbext_pk_Proc) <> strProc Then
strProc = .CodeModule.ProcOfLine(iCount, vbext_pk_Proc)
strNames = strNames & vbTab & vbTab & strProc & vbCrLf
End If
Next iCount
End With
Next myComponent
strDocNames = strDocNames & vbCrLf & strNames
End If
End If
Next myProject
Debug.Print strDocNames

'Datenbank schließen
Datenbank.Close

End Sub
 

Lesen sie die antworten

#1 Stefan Ruppel
27/11/2009 - 16:26 | Warnen spam
Du hast völlig recht: Pferd von hinten und völlig idiotisch stimmt alles!!

Die Vorgeschichte:
- ich habe hier rel. große DB'S (und jeden Monat kommen neue hinzu) und
rechne dort Risikogewichte nach Basel II. Das geht unter ACCESS auch alles
prima. Aber meine Chefin hat keine Ahnung von ACCESS (und von EXCEL glaube
ich auch nicht viel mehr, aber dort glaubt sie sie kennt sich aus) und will
daher das ganze unter Excel haben. Eine volle Migration nach Excel macht
keinen Sinn (sonst Pflege/Warte ich in Zukunft alles x-fach).
Daher war die Idee:
Laß die benötigten Daten auswàhlen (DB+Tabelle) - ev. auch mehrere
und lade das Ganze dann in ein Excelworksheet + Aufbereitung zur Analyse.

Dann such eine Accessfunktion im Programmmodul meiner Anwendungen (hier:
BaselII-Funktion) aus einer Liste aus und laß die Funktion in EXCEL unter
Rückgriff auf die ACCESS Funktion rechnen. D.h. die 'runtergeladene
Excel-Liste liefert die Daten und die EXCEL Funktion (die eine ACCESS
Funktion ist und dort arbeitet) liefert die Werte. --> Die entsprechenden
Werte 'runterzuladen wàre natürlich eine Möglichkeit, aber Chefin will ja mit
den Daten spielen und zumindest so tun als ob sie simuliert (darum geht es).

Damit bleiben die Funktionen wo sie hingehören. Auf die Listenauswahl könnte
ich verzichten (ich kenn ja meine Funktionen) - gehört aber natürlich
eigentlich auch zu einer guten Oberflàche dazu.
Aber heute nachmittag stelle ich zu meinem Entsetzen fest, daß das mit dem
Funktionszugriff auch nicht so einfach ist wie ich eigentlich dachte.

Ich habe mir dazu folgende Funktion aus dem Internet besorgt:

Sub CallAccessMacro()
Dim accApp As Object
Dim sFile As String
sFile = Range("B1").Value
If Dir(sFile) = "" Then
Beep
MsgBox "Access-Datenbank wurde nicht gefunden!"
Else
Set accApp = CreateObject("Access.Application")
accApp.OpenCurrentDatabase sFile
accApp.Run "Meldung"
accApp.CloseCurrentDatabase
Set accApp = Nothing
End If
End Sub

Aber da wird es wohl Probleme geben, weil die ja eigentlich eine Sub
aufruft. Ob man das in einen Function Aufruf umbauen kann weiß ich noch nicht.

IMHO ist es absurd in mit EXCEL als Rahmen eine (noch dazu komplexe) ACCESS
Anwendung zu fahren. Dazu habe ich auch 'mal einen Post dazu gesehen, deer
das sehr kritisch beurteilte. Aber das bisherige Ergebnis meiner Bemühungen
ist auch nicht ganz ohne und schaut auch noch ganz gut aus. ...und weißt
Du wenn's der Chefin halt so gefàlltna ja.

Hatte mich zeitweise auch um Laufzeitoptimierung gekümmert.Quatsch,
jetzt schaue ich nur noch daß sich am Schirm möglichst viel
tutExperten und so.

Kleiner Scherz: .suche noch eine Routione, die den Bildschirm an den
richtigen Stellen zum wackeln bringt .. oder etwas in der Art.

Nichts für ungut!

Trotzdem schöne Grüße!

Stefan

PS: ich denke das Ganze könnte für andere auch interessant sein und werde
das gel. ins Netz stellen (nur die BaselII - Funktion definitiv nicht)




"Thomas Winkler" wrote:

Hallo Stefan,

auch wenn ich nichts sinnvolles zu Deiner Frage beitragen kann:

1. Das könnte vielleicht in der Excelgroup besser aufgehoben sein, weil
Du ja in Excel programmierst.

2. Ich habe das Gefühl dass Dein ganzes Vorgehen bzw. das dadurch
geschaffene Gebilde von Grund auf hinkt. Du zàumst das Pferd von hinten
auf. Von "unten" (Excel) aus das "oben" (Access) steuern zu wollen hat
für mich etwas befremdliches - Stichwort "Frickelei".

Warum willst Du denn Funktionen in Excel nutzen, die in Access
programmiert sind. Bzw. warum sind die nicht in Excel programmiert, wenn
sie dort gebraucht werden?

Warum übernimmst Du die Funktionen für die Excel jetzt eingesetzt werden
soll/wird nicht mit nach Access und ersetzt Excel damit vollstàndig?
Damit schaffst Du höhere Datenkonsistenz, bessere Performance, gerinere
Abhàngigkeiten und vermeidest Schnittstellen.

Lass mich raten... Weil die User nur Excel "können"/wollen?
Das zieht aber nicht als Grund. :-)

Thomas

"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
.

Ähnliche fragen