Hallo allerseits, Neuzugang grüsst höflichst...
Scheint eine ziemlich rege und technisch versierte Forum zu sein, ich bin gespannt, ob jemand ähnliche Erfahrungen hat und vielleicht einen Tipp geben kann. Sorry, jetzt wird es lang:
Also - Kunde, ziemlich komplexe Verwaltungsprogramm, vor 8-9 Jahren in Access 2003 mit SQL 2000 (damals State-Of-The-Art) entwickelt. Natürlich will der Kunde keinen Cent mehr reinstecken, das Programm soll auch noch in 30 Jahren laufen, Garantie ist ohnehin lebenslänglich... Von einer Portierung auf .NET will er nichts hören... Wahrscheinlich einige von Euch kennen die Situation ;)
Office 2003 Lizenzen gibt es ja nicht mehr, auf 2010 zu portieren wäre zu aufwendig, Abwärtskompatibiität ist ja nicht mehr gegeben seit der Ribbons, also als die erste PCs den Geist aufgegeben haben, müsste Win7 mit Access 2003 Runtime herhalten. Ich habe da einige Sachen anpassen müssen, aber im Endeffekt habe ich es zum Laufen gebracht und dachte jetzt ist eine Zeitlang erledigt...
Jetzt gibt es einige neue PCs, alles von der Hand frisch und relativ sauber aufgesetzt - und KNALL! :o eine für mich unerklärliche Phenomän:
Ich habe ADP files modular aufgebaut, die einzelnen Module werden in eigenen Instanzen von Access geöffnet. So ungefähr nach der Schema: starte neue Runtime Instanz, dann late binding mit GetObject um die Access.Application zu finden, dann Application.OpenAccessProject, Application.DoCmd.OpenForm ... mit OpenArgs, dann API ShowWindow um alles anzuzeigen.
Die Formulare die dabei geöffnet werden, werden über die OpenArgs in Form_Open gesteuert - entweder Neuanlage, dann wird der entsprechende Table in der Form.RecordSource gestellt und Form.DataEntry = True gesetzt, oder es soll eine im Hauptmodul gewählte Datensatz geöffnet werden. In diesem Fall wird der RecourdSource auf "SELECT * FROM xyc WHERE ID=" & Me.OpenArgs (so in etwa) gesetzt.
Voilá, alle sind glücklich, alles funktioniert, es gibt etwa 10 Module nach dem gleichen Schema. Öffnen der Module erfolgt, wie oben beschrieben, über VB Code, wo der Modulname als Parameter mitgegeben wird: also OpenModule("Partner") -> öffnet "Partner.adp", OpenForm "frmPartner", "SELECT * FROM tblPartner WHERE ..." oder auch öffne "Rechnung.adp", OpenForm "frmRechnung", "SELECT * FROM tblRechnung.." usw, usw.
So und jetzt: es gibt EINEN Modul, der aus irgendeiner Grund nicht will. ??? Code ist identisch, Einstellungen sind identisch, unter XP und Vollversion von Access funktioniert, unter Windows7 mit Runtime funktioniert aber auf die neuen PCs mit Win7 (4 x) bleibt das Formular leer (grauer Hintergrund).
Die Geräte haben einen identischen Stand: sowohl der "alte" Win7 als auch die neuen haben alle derzeit verfügbaren Patches installiert.
Jetzt wird ein bisschen unheimlich :) Im Code rennt alles durch, ich habe mit MsgBox immer wieder anzeigen lassen, wo es gerade steckt... Form_Open rennt durch, Recordsource wird richtig gesetzt, ein Datensatz wird gefunden, Datensatz wird geladen, ich kann Felder aus der Datensatz mit MsgBox anzeigen, Form_Current wird ausgelöst, alles ist da - nur die Anzeige fehlt... Neuanlage mit DataEntry=True funktioniert also es kann nicht an Formular selbst oder an einer der Controls liegen.
Ich habe schon so manches mit Access erlebt, kann ja sein, dass die Datei beschädigt ist, also ADP komplett neu angelegt, alles importiert - Verhalten unverändert. Also vielleicht liegt an die Daten, also mit einen anderen Tabelle probiert - bleibt grau. In der Statusleiste zeigt die ControlTipText der Felder an, mit Tab springt weiter, alles ist da und funktionstüchtig - "nur" nicht sichtbar. Na gut, dann händisch komplett neu aufgebaut ohne etwas zu importieren - bleibt grau.
Damit ist der einzige, was das Modul von anderen unterscheidet ist die Name, aber ich glaube kaum, dass "frmShipment" oder "tblShipment" reservierte Wörter in der Runtime sind :) Die neun andere Module funktionieren einwandfrei, der eine verweigert. Wohlbemerkt, nur auf den neuen Rechner, auf einer Win7 Maschine der etwa vor 6 Monaten dazukam, funktioniert alles.
Soooo, das ist jetzt ganz schön ausführlich geworden, sorry, aber es ist halt ein komplexes Problem. Hat jemand bis hierher gelesen? Und sogar vielleicht auch noch eine Idee?
Ich wäre für Euren Beitrag sehr dankbar, liebe Grüße aus Wien, R.
Hallo,
mal eine Frage am Rande, wieso hast du das mit einer ADP aufgebaut?
Weil eine normale MDB läuft i.d.R. ohne Hand anzulegen auch unter Access 2010.
Zum eingentlichen Problem kann ich dir nicht weiterhelfen. Wenn es nur 1 PC wäre könnte man auf Hardwarefehler vieleicht schließen. Überprüfe mal die Umgebungseinflüsse, also installierte Programme wie Vierenscanner, Windows Einstellungen etc.
Andreas
Hi Andreas, danke für Dein Beitrag.
ADP war anno dazumal "state-of-the-art" und ohne Jet wesentlich performanter mit SQL Daten. SQL Server war mehr oder weniger vorgegeben oder zwingend, die Datenmengen hätte ich Access alleine nicht anvertraut (es handelt sich um eine Art Warenwirtschaftsystem mit 80.000 Artikeln, jede Menge Abbildungen, Webshop Anbindung, 8-10 User). Die Entschedung für den Front End ist auf Access gefallen, weil hier agiler gearbeitet werden konnte - nachdem der Kunde nicht wusste was er haben will, war es mangels Spezifikation so quasi als rapid prototyping Umgebung eingesetzt :)
MDB stimme ich Dir nur bedingt, bzw. unter Betonung von "normal" zu. Meine Erfahrungen mit Portierung auf Access 2K7 und 2010 waren weniger rosig, sobald die Möglichkeiten von "reinen" Access ausgereizt wurden und VB Code über if, else, OpenForm eingesetzt wurde (vor allem API oder COM Komponenten oder eigene OCX Controls), lief nichts mehr auf Anhieb. Einige Techniken, die in Access 2003 reibungslos gelaufen sind, habe ich neu entwickeln müssen, andere habe ich einfach nicht mehr zum Laufen gebracht.
Hardware wird es kaum sein, nachdem gleichzeitig 4 neue PCs davon betroffen sind. Umgebungseinflüsse wären natürlich eine Erklärung, was mich allerdings stutzig macht, dass es wie erwähnt bei 9 anderen Modulen mit der gleichen Technik funktioniert.
Das ganze schaut für mich so aus, als ob der Runtime sich verschlucken würde - eigentlich der dunkelgraue Hintergrund mit unsichtbaren Formular ist genau das, was der Runtime z.B. mit der Datenbankfenster macht... es ist zwar da und funktioniert aber bleibt versteckt.
Ich suche noch verzweifelt nach einer Lösung, lg, R.
Hallo,
ADPs sind heute eigentlich out, wenn es nicht um verteilte Standorte geht.
Du kannst alles auch mit MDBs und wahrscheinlich auch mit Accdbs machen.
Warum willst du das nicht unter Access 2003 weiterlaufen lassen?
Ich entwickel heute noch darunter und teste unter 2010. Mittels einer Runtime benötigst du auch keine Lizensen.
Andreas
Hallo,
hier könnte auch ein Problem mit den Verweisen vorliegen. Das unterschiedliche Verhalten von scheinbar gleichen Rechnern lässt das vermuten. Besonders bei Einsatz einer Runtime müssen die Verweise in VBA gesetzt werden. Wenn ich mich nicht irre, ist das das sogenannte Late Binding.
Es gibt sicher noch mehr Infos dazu. Google mal nach "Late Binding".
Aber ich kann da nicht beraten, habe keine Erfahrung. Betrachte das nur mal als Hinweis zur weiteren Fehlersuche.
imo sollte auch Late Binding mit der Runtime möglich sein.
Einzig was mit der Runtime nicht geht nachträglich Verweise per VBA zu setzen.
Gruß Andreas
Hallo,
Zitatimo sollte auch Late Binding mit der Runtime möglich sein.
ja, aber es muss in der Originaldb gemacht werden damit eine Runtime fehlerlos funktioniert.
Und da können sich verschiedene scheinbar gleiche Rechner unterschiedlich verhalten.
Äh, ja logisch, in der Runtime kannst ja nix machen von wegen mit Code.
Andreas
Hallo,
ZitatSo und jetzt: es gibt EINEN Modul, der aus irgendeiner Grund nicht will. Code ist identisch, Einstellungen sind identisch....
...macht mich irgendwie stutzig - irgend ein Unterschied außer den Benamsungen muss bestehen.
Hast du schon mal versucht einfach die Formularnamen und Tabellennamen in diesem seltsamen Modul auf funktionierende Varianten auszutauschen - auch wenn das Ergebnis dann keinen datenbezogenen Sinn ergäbe - nur um zu sehen, ob ein anderes Formular mit diesem Modul geöffnet UND angezeigt werden kann.
Versuche auch das Modul sowie die Routine anders zu benennen.
Zuerst einmal Danke an alle für die Anregungen!
Verweise sind heikel, weil Access hier gerne "nach oben" im Hintergrund aktualisiert und dann auf einen Rechner mit den alten Versionen damit nichts mehr anfangen kann. Also hier habe ich alles duchgecheckt, alles vorhanden, keine Probleme.
Zur besseren Verständnis kurz die Umgebung: ich habe einen XP Rechner mit Office 2010 ohne Access und Access 2003 Vollversion. Hier sind alle COM Voraussetzungen auch richtig installiert, wie PDFCreator, Etikettendrucker, OCX Controls, usw. Auf diesem Rechner entwickle bzw. gebe ich eine Version frei. Freigegebene Versionen werden auf alle Rechner automatisiert verteilt und auch nach broken references durchgecheckt. Auf der Arbeits PCs ist nur noch der Runtime installiert. Dies alles funktioniert trotz "gemischter" Umgebung mit teilweise XP, teilweise Win7 recht gut und zuverlässig.
Komischer Aspekt: auch die Rechner, wo es funktioniert, sind gleich konfiguriert, ich habe Win7 und auch XP Rechner mit ebenfalls 2003 Runtime, wo es funktioniert. Es wurde ausser der Runtime sicherlich nichts extra dazu installiert, wie irgendwelche Data Components o.ä. Einfach Windows, Office 2010, Zusatzprogramme wie PDFCreator, Runtime -> alle patches von MS Update und am Ende Applikation.
Also Verweise kann ich generell, glaube ich, ausschließen.
Mich macht die ganze Geschichte auch irgendwie stutzig :D
Ich habe nämlich auch schon mit Peter's Vorschlag durchgespielt: NEUE ADP händisch angelegt, Formular NEU erstellt, ANDERE Tabelle ein paar Felder eingefügt und NUR Me.RecordSource = "SELECT * FROM AndereTabelle" im Code gelassen... Ergebnis: dunkelgraue Applikationshintergrund im leeren Fenster! Formular ist aber da und funktionstüchtig, mit TAB komme ich von Feld zu Feld, unten in der Statusleiste zeigt ja die StatusBarText... "Nur" alles eben unsichtbar.
Einzig mit anderen Namen habe ich noch nicht probiert, weil ich dafür einiges im Hauptmodul umkonfigurieren müsste - aber es wird mir wohl nicht erspart bleiben...
Zitat... irgend ein Unterschied außer den Benamsungen muss bestehen
Tja... da stimme ich Dir voll und ganz zu, nur ???
lg, R.
Hallo,
ich sehe hier nach wie vor die Verweise als Ursache. Du kannst auch auf den Rechnern mit der Runtime die Verweise gar nicht so ohne weiteres prüfen. Und dass die Installationen gleich sind, siehst Du nur oberflächlich, die Verweise der Runtimrechner kannst Du ja gar nicht prüfen. Du kommst ja gar nicht in das entsprechende Fenster.
Ich werde mal die Verweise Vorort nochmals durchgehen und lasse es Euch wissen.
Ich habe bisher die Erfahrung gemacht, dass man sehr wohl an die Verweise dran kommt, auch im Runtime - nur mit MDE oder ADE ginge es nicht, weil dort der Code gesperrt ist und nur noch kompiliert vorliegt.
Einfach eine ; separated string zusammnebasteln und dann in ein Listview als RowSource anzeigen. Hier mein Code (im Form_Open), Form soll ein ListView namens Detail haben mit 6 Columns, RowSourceType="Value List", ColumnWidths="5cm;2cm;2cm;8cm;2cm;6cm":
Dim Ref As Reference, TmpRef As String
TmpRef = "Reference;Version;Status;Path;Type;GUID;"
On Error GoTo RefError
For Each Ref In References
TmpRef = TmpRef & Ref.Name & ";"
TmpRef = TmpRef & Ref.Major & "." & Ref.Minor & ";"
TmpRef = TmpRef & IIf(Ref.IsBroken, "#ERROR;", "OK;")
TmpRef = TmpRef & Ref.FullPath & ";"
TmpRef = TmpRef & IIf(Ref.Kind = Project, "Project;", "TypeLib;")
TmpRef = TmpRef & Ref.GUID & ";"
Next Ref
On Error Resume Next
Me!Detail.RowSource = TmpRef
Übrigens - beim Update gehe ich eine ähnliche Schleife durch und falls IsBroken, schmeiss ich ein Exception. Hat mich schon oft gerettet, als auf mein Entwicklungsrechner z.B. PDFCreator aktualisiert wurde und auf der Zielrechner noch die alte Version vorlag.
ABER: ich habe im z.B. Partnermodul die gleichen Referenzen, wie im Lieferschein. Partnermodul geht, Lieferschein bleibt grau...
Nichdestotrotz, ich checke nochmals die Verweise - wer weiss?
Danke, lg, R.