Wir benutzen schon seit Jahren eine selbstgebastelte Anwendung zum Schreiben von Angeboten.
Diese wurde mit Access 2003 entwickelt und seit einiger zeit auch auf PC's mit
der deutschen 2007er Runtime ausgeführt.
Der Berichtsaufruf funktionierte stets einwandfrei.
Nun wurde ein Bericht ohne ausgedruckte Preise benötigt.
eigentlich kein Problem...
Bericht unter neuem Namen abspeichern, neuen Button anlegen.
Code kopieren, ändern, neuer Berichtsname etc.
Ist alles schnell erledigt und funktioniert auch mit Access 2007.
Auf PC's mit der Runtime Version erhalte ich allerdings einen Laufzeitfehler.
Fehlermeldung:
Die Ausführung dieser Anwendung wurde wegen eines Laufzeitfehlers angehalten.
Die Anwendung kann nicht wieter ausgeführt werden und wird beendet.
Jetzt wird es seltsam:
Auch der ursprüngliche Button, an dem nichts geändert wurde führt zum Laufzeitfehler.
Der Code:
Private Sub Befehl51_Click()
On Error GoTo Err_Befehl51_Click
Dim Angebotsname As String
Dim Bedingung As String
Angebotsname = "Angebot" & Nz(Me!Angebot) _
& "-" & Nz(Me!Kurz) _
& "-" & Nz(Me!Bezeichnung)
Debug.Print Angebotsname
Dim stDocName As String
Bedingung = "Angebot = " + Str(Form_15_Angebot![Angebot])
Debug.Print Bedingung
stDocName = "Angebot_als_Ausschreibung"
DoCmd.OpenReport stDocName, acViewPreview, , Bedingung
Reports![Angebot_als_Ausschreibung].Caption = Angebotsname
Exit_Befehl51_Click:
Exit Sub
Err_Befehl51_Click:
MsgBox Err.Description
Resume Exit_Befehl51_Click
End Sub
Ich hoffe, jemand kann weiterhelfen.
Hallo,
ohne Gewähr auf Problemlösung würde ich erst den Code so schreiben:
Private Sub Befehl51_Click()
On Error GoTo Err_Befehl51_Click
Dim Angebotsname As String
Dim Bedingung As String
Angebotsname = "Angebot" & Nz(Me!Angebot,"") _
& "-" & Nz(Me!Kurz,"") _
& "-" & Nz(Me!Bezeichnung,"")
Debug.Print Angebotsname
Dim stDocName As String
Bedingung = "Angebot = '" & Me![Angebot] & "'" ' falls Angebot in der Tabelle vom Datentyp Text ist, ansonsten die Hochkommata weglassen
Debug.Print Bedingung
stDocName = "Angebot_als_Ausschreibung"
DoCmd.OpenReport stDocName, acViewPreview, , Bedingung,,Angebotsname
Reports![Angebot_als_Ausschreibung].Caption = Angebotsname ' dieses in Report_Open-Prozedur verlagern.
Exit_Befehl51_Click:
Exit Sub
Err_Befehl51_Click:
MsgBox Err.Description
Resume Exit_Befehl51_Click
End Sub
Sub Report_Open(..)
If Not Isnull(Me.Openargs) Then Me.Caption = Me.Openargs
End Sub
Weiterhin mit der Vollversion die Verweise auf evtl. Fehler prüfen, den Code kompilieren und speichern.
Vielen Dank für die schnelle Hilfe.
Es hat funktioniert.
Der Fehler lag bei der Bedingung.
Leider hat sich das Problem ausgeweitet.
Schon der einfache Aufruf eines Formulars aus dem Switchboard führt zum Absturz.
An einer anderen Stelle ist es die Verwendung von ADO.
Im Moment fällt mir nichts besseres ein als noch einige Vollversionen
zu kaufen und zu installieren.
Das Debuggen ist äusserst zeitaufwändig.
Ich teste momentan mit einer virtuellen Maschine auf der die Runtime Version installiert ist
und ändere den Code zeilenweise mit der Vollversion.
Auch das Setzen eines EXIT SUB in den betroffenen Code bringt nichts,
auch bei einem Fehler nach dem EXIT SUB kommt der Programmabsturz.
Damit ist das komplette Debuggen wertlos, wenn man die Runtime Version verwenden
will. Eventuell ist man besser beraten, gleich in Visual Basic zu programmieren.
Was denkt Ihr darüber?
Hallo,
ich denke, dass unsauber programmierter Code nicht durch Make Up übertüncht werden kann. Es müssen die Ursachen korrigiert werden.
Da hilft auch der Kauf einer Vollversion nichts, weil dort genausogut unerklärliche Abstürze auftreten können.
Genauso wenig läuft solcher Code in VB (meinst Du damit VB6/Visual Studio oder .Net? )
Wenn in allen(!!) Modulköpfen noch nicht
Option Explicit
eingebaut ist, dann hole das zunächst nach und kompiliere die DB anschliessend. Auftauchende angemeckerte Codestellen MÜSSEN korrigiert werden, solange, bis eine vollständige Kompilierung möglich ist und egel, wie aufwändig das sein sollte.
Auf Code, der sich ändernd auf ein Objekt (Formular/Bericht) auswirkt, muß dringend verzichtet werden, weil solcher Code prinzipiell in einer Runtime-Umgebung nicht läuft.
Desweiteren ist auf eine übereinstimmte Installation von ext. Programmteilen (dlls , ActiveX, etc) auf den verschiedenen Rechnern zu achten, damit keine gebrochenen/fehlende Verweise entstehen.
Um eine Runtime-Umgebung zu simulieren, kann die Access-Vollversion mit dem Start-Schalter /Runtime gestartet werden.
Wenn der Code schon nicht mit Access-VBA in einer Access-Db problemlos abläuft, wird es mit einer anderen Programmiersprache/-umgebung erst recht zum Chaos kommen.
Hauptproblem waren wohl die Verweise.
Ich habe ein Unterprogramm gefunden, das alle Verweise mit debug.print ausgibt.
Anschliessend habe ich alle Verweisdateien ins Installationsverzeichnis
der Runtime Version kopiert.
Die Verlagerung des Codes für die Caption Eigenschaft ist ein sehr guter Tipp.
Option Explicit hatte ich fast überall gesetzt.
Der Aufwand hielt sich hierdurch auch in Grenzen.
Vielen Dank für die Unterstützung :)