Umstieg von A2002 nach A2007, soll ich ?

59 views
Skip to first unread message

Remi Noel

unread,
Apr 29, 2008, 11:21:43 AM4/29/08
to
Hallo NG

Xp-home SP2
ich möchte (noch)kein Vista weil ich einige Uralt-Programme benutze und mein
System sehr stabil laüft!

Ich benutze A2002 und habe (mühsam) private Anwendungen (mit Hilfe aus der
NG hier!!) aufgebaut.
Nicht perfekt programmiert, aber es funtioniert alles tadellos (wenn
wahrscheinlich vom Umfang der Programmierung um das 5fache zu groß).
Jetzt kann ich SEHR günstig A2007 beziehen bin aber nach dem lesen einiger
NG-Beiträge total unsicher.

1. Kann ich problemlos A2007 parallel zu A2002 installieren?
2. wenn ja, funktionieren dann meine A2002 Anwendungen noch?

3. wenn nein, muß ich nach der Installation von A2007 alle A2002
konvertieren
und funktionieren dann meine A2002 Anwendungen noch?

PS. ich benutze auch intensiv excel, word 2002.

Danke für hilfreiche feedbacks


Remi

Mark Doerbandt

unread,
Apr 29, 2008, 11:54:34 AM4/29/08
to
Hallo, Remi,

Remi Noel:

> aber es funtioniert alles tadellos

never change a running system.

Gruss - Mark

--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm

Bitte keine eMails auf Newsgroup-Beiträge senden.

Peter Doering

unread,
Apr 29, 2008, 12:30:53 PM4/29/08
to
Hallo,

Remi Noel wrote:

> Xp-home SP2
> ich möchte (noch)kein Vista weil ich einige Uralt-Programme benutze und mein
> System sehr stabil laüft!

Sehe ich wie Mark. Wenn du keine Not hast, lass es...



> Ich benutze A2002 und habe (mühsam) private Anwendungen (mit Hilfe aus der
> NG hier!!) aufgebaut.
> Nicht perfekt programmiert, aber es funtioniert alles tadellos (wenn
> wahrscheinlich vom Umfang der Programmierung um das 5fache zu groß).
> Jetzt kann ich SEHR günstig A2007 beziehen bin aber nach dem lesen einiger
> NG-Beiträge total unsicher.
>
> 1. Kann ich problemlos A2007 parallel zu A2002 installieren?

Definiere problemlos. Es funktioniert, aber der wechselweise Start dauert
relativ lange, laenger als z.B. A97 und A03 am gleichen Rechner.

> 2. wenn ja, funktionieren dann meine A2002 Anwendungen noch?

Normalerweise schon. Aber das musst du selbst ausprobieren.

> 3. wenn nein, muß ich nach der Installation von A2007 alle A2002
> konvertieren

Nein! Du kannst bestehende mdbs ab A00 bearbeiten und auch neue anlegen.

> und funktionieren dann meine A2002 Anwendungen noch?

s.o. Probier's aus.

> PS. ich benutze auch intensiv excel, word 2002.

Erwaehnst du das, weil du Automation benutzt? Falls ja, und wenn diese
Versionen parallel installiert bleiben sollen, musst du beim Aufruf die
entsprechende Version angeben, z.B.

CreateObject("Word.Application.10") 'A02

Gruss - Peter

--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com

Remi Noel

unread,
Apr 29, 2008, 12:34:27 PM4/29/08
to
Hallo Mark

Das ist auch meine Devise aber neugierig wäre ich doch zu meine Fragen etwas
zu lesen :-))

Gruß
Remi

"Mark Doerbandt" <spamre...@doerbandt.de> schrieb im Newsbeitrag
news:fv7ncq...@dit8.doerbandt.de...

Remi Noel

unread,
Apr 29, 2008, 12:39:49 PM4/29/08
to
Hallo Mark

Das ist auch meine Devise aber neugierig wäre ich doch zu meine Fragen etwas
zu lesen :-))

Gruß
Remi

"Mark Doerbandt" <spamre...@doerbandt.de> schrieb im Newsbeitrag
news:fv7ncq...@dit8.doerbandt.de...

Martin Meyer

unread,
Apr 29, 2008, 1:11:36 PM4/29/08
to
Hallo Peter,

On Tue, 29 Apr 2008 18:30:53 +0200, Peter Doering <nos...@doering.org>
wrote:

>
>Erwaehnst du das, weil du Automation benutzt? Falls ja, und wenn diese
>Versionen parallel installiert bleiben sollen, musst du beim Aufruf die
>entsprechende Version angeben, z.B.
>
>CreateObject("Word.Application.10") 'A02

Schön wärs :(
Das kannst Du getrost knicken und Dir die Angabe der Versionsnummer (hier
die 10) sparen. Du bekommst eh nur die neuste installiert Word.App
instanziert. Auch hier hat MS allen neueren Wordversionen schlauerweise
die gleiche CLSID verpasst (000209FF-0000-0000-C000-000000000046),
so dass Du immer nur die Instanz bekommst, die unter
HKLM\SOFTWARE\Classes\CLSID\{000209FF-0000-0000-C000-000000000046}\LocalServer32
eingetragen ist.

createobject ("Word.Application.8").visible= true
startet hier auf dieser Kiste (winword 8 und 10 installiert) zB. immer
WordXP, auch wenn ich vorher Word97 als letztes benutzt habe.

cu,
Martin

--
Bei Antworten per eMail bitte an die Reply-To Adresse senden.
Oder der From-Adresse den String "nospam_" voranstellen.
eMails an die unmodifizierte From-Adresse werden ungelesen geloescht.

Winfried Sonntag

unread,
Apr 29, 2008, 1:21:35 PM4/29/08
to
Mark Doerbandt schrieb:

> never change a running system.

Aber doch nicht hoffentlich so:
http://www.guug.de/lokal/karlsruhe/2003-06-03/never-touch_d.pdf
;-)

Servus
Winfried
--
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
KnowHow.mdb: http://www.freeaccess.de/knowhow.asp
Access-FAQ: http://www.donkarl.com/AccessFAQ.htm
Access-Stammtisch: http://www.access-muenchen.de

Sascha Trowitzsch

unread,
Apr 29, 2008, 2:09:40 PM4/29/08
to
Hi Martin,

"Martin Meyer" <mme...@nurfuerspam.de> schrieb im Newsbeitrag
news:scke14lc071219aon...@4ax.com...


> Hallo Peter,
>
> On Tue, 29 Apr 2008 18:30:53 +0200, Peter Doering <nos...@doering.org>
> wrote:
>>CreateObject("Word.Application.10") 'A02
>
> Schön wärs :(
> Das kannst Du getrost knicken und Dir die Angabe der Versionsnummer (hier
> die 10) sparen. Du bekommst eh nur die neuste installiert Word.App
> instanziert. Auch hier hat MS allen neueren Wordversionen schlauerweise
> die gleiche CLSID verpasst (000209FF-0000-0000-C000-000000000046),
> so dass Du immer nur die Instanz bekommst, die unter
> HKLM\SOFTWARE\Classes\CLSID\{000209FF-0000-0000-C000-000000000046}\LocalServer32
> eingetragen ist.

Ist richtig.
Es hört sich bei dir aber so an, als wäre es blöd von MS, allen Versionen die
gleiche CLSID zu geben. Das sehe ich aber nicht so. Hast du dir die Konsequenz
überlegt, was wäre, wenn alle Versionen unterschiedliche CLSIDs hätten? Dann
würde eine Menge Kompatbilität flöten gehen!

Ciao, Sascha


Martin Meyer

unread,
Apr 29, 2008, 3:24:45 PM4/29/08
to
Hi Sascha,

On Tue, 29 Apr 2008 20:09:40 +0200, "Sascha Trowitzsch" <n...@moss-soft.de>
wrote:

>[...]


>Es hört sich bei dir aber so an, als wäre es blöd von MS, allen Versionen die
>gleiche CLSID zu geben.

Ja ich finde es auch blöd ;-)

Und ehrlich gesagt, würde ich es auch schlichtweg als Bug bezeichnen,
wenn die Klasse XX anfordere, aber kommentarlos die Klasse XY als Instanz
untergeschoben bekommen - auch wenn der Bug hier 'by Design' ist.

> Hast du dir die Konsequenz
>überlegt, was wäre, wenn alle Versionen unterschiedliche CLSIDs hätten?

Kann ich Dir nicht sagen, ob das nicht auch anders lösen könnte, weil ich
einfach zu wenig über das Konzept weiss. Ich habe irgendwie das Gefühl,
dass dieser Weg zur Kompatibilität über die gleiche CLSID mit der "groben
Kelle" gemacht ist.

Ich bin mir auch nicht sicher, ob ich diese ganze "Kompatibilität"
brauche und will, die MS für mich vorsieht. Klar soll alles ganz easy und
schmerzarm gehen in der Windows-Welt -wogegen auch nix einzuwenden
ist- aber viele Automatiken, Information-Hiding .. usw... gehen nach
hinten los, führen zu Bugs (wie diesen), Sicherheitslücken ... und gehen
in Richtung User-Entmündigung.

>Dann würde eine Menge Kompatbilität flöten gehen!

In diesem Fall zB. welche Kompatibilität speziell?
(Frage ist keine Provokation, sondern aus Unwissenheit und aufrichtigem
Interesse).
Bei anderen Produkten kann ich auch diverse Programm-Versionen völlig
ohne gegenseitige Beeinflussung parallel nutzen.

Gruß,

Mark Doerbandt

unread,
Apr 29, 2008, 4:20:34 PM4/29/08
to
Hallo, Winfried,

Winfried Sonntag:

>> never change a running system.
>
> Aber doch nicht hoffentlich so:
> http://www.guug.de/lokal/karlsruhe/2003-06-03/never-touch_d.pdf
> ;-)

;-) interessant, vielen Dank!

Aber: doch, genau so, wie da auf Seite zwei, zweiter Absatz, letzter
Satz beschrieben. Das ist genau der Fall von Remi. Hier: "unnötig".

Gruss - Mark

Mark Doerbandt

unread,
Apr 29, 2008, 4:46:27 PM4/29/08
to
Hallo, Remi,

Remi Noel:

> Das ist auch meine Devise aber neugierig wäre ich doch zu meine Fragen etwas
> zu lesen :-))

ich kann dazu leider nicht viel mehr sagen, als dass ich das (parallel
installieren) nicht (mehr) mache und auch nicht (mehr) empfehle.
Funktionieren wird es wohl (ein Weilchen, aber wer weiss wie
lange?)...

Peter Doering

unread,
Apr 29, 2008, 9:12:20 PM4/29/08
to
Hallo Martin,

Martin Meyer wrote:


> Peter Doering wrote:
>>
>>Erwaehnst du das, weil du Automation benutzt? Falls ja, und wenn diese
>>Versionen parallel installiert bleiben sollen, musst du beim Aufruf die
>>entsprechende Version angeben, z.B.
>>
>>CreateObject("Word.Application.10") 'A02
>
> Schön wärs :(
> Das kannst Du getrost knicken und Dir die Angabe der Versionsnummer (hier
> die 10) sparen. Du bekommst eh nur die neuste installiert Word.App
> instanziert.

Nachdem ich das in der Vergangenheit fuer Access immer wieder mal
erfolgreich eingesetzt hatte, hab ich das jetzt nochmal in einer VM in
allen Kombinationen getestet. Zunaechst, meine Erinnerung war korrekt, was
Access angeht, und zwar mit den Versionen A97 und A02. Folgende Prozedur
funktioniert, egal ob man sie unter A97 oder A02 ausfuehrt:

Sub TestAutomation()
Dim Obj1 As Object
Dim Obj2 As Object

Set Obj1 = CreateObject("Access.Application.8")
Set Obj2 = CreateObject("Access.Application.10")

With Obj1
.Visible = True
.UserControl = True
End With

With Obj2
.Visible = True
.UserControl = True
End With

Set Obj1 = Nothing
Set Obj2 = Nothing
End Sub

Ergebnis: A97 und A02 wurde jeweils korrekt geoeffnet, egal wo die Prozedur
lief. Damit war's das aber auch. :-(

Die gleiche Prozedur um Access.Application.11 erweitert hat das Objekt
jeweils in der Version erstellt, in der die Prozedur ausgefuehrt wurde,
bzw. von A97 aus die, die vor A97 zuletzt gestartet worden war. Nur A97
wurde immer verlaesslich erstellt.

Bei Word und Excel war das Ergebnis leider noch eindeutiger, es wurden
immer .11 gestartet, egal von wo, egal welche Nr.

> createobject ("Word.Application.8").visible= true
> startet hier auf dieser Kiste (winword 8 und 10 installiert) zB. immer
> WordXP, auch wenn ich vorher Word97 als letztes benutzt habe.

Das deckt sich leider mit meinem Ergebnis.

Remi Noel

unread,
Apr 30, 2008, 3:10:52 AM4/30/08
to
Danke Mark

Ich hab alles hier verfolgt und auch die "soll-ich-pdf" gelesen.
Entscheidung ist klar:
System ok, Access Anwendungen mit Excel- und Word- und
Serienbriefe/Mails -Verbindungen einwandfrei.
Es besteht kein zwingender Grund und für das gesparte Geld kauf ich mir ein
Eis :-)))

Danke Euch für die Beiträge

Grüße

Remi

"Mark Doerbandt" <spamre...@doerbandt.de> schrieb im Newsbeitrag

news:fv88g3...@dit8.doerbandt.de...

Sascha Trowitzsch

unread,
Apr 30, 2008, 5:47:32 AM4/30/08
to
Hi Peter,

"Peter Doering" <nos...@doering.org> schrieb im Newsbeitrag
news:67pvbmF...@mid.individual.net...

Die CLSID der Type Library von A97 und die der nachfolgenden Versionen
unterscheiden sich.
Das heißt, dass man A97 sehr wohl mit der entspr. ProgID starten kann. Ab A2000
ff. dann nicht mehr, weil alle die gleiche Type Library GUID haben.
Der Grund für den Wechsel liegt wohl darin, dass 97 und ff. unterschiedliches
VBA besitzen.

Ciao, Sascha


Sascha Trowitzsch

unread,
Apr 30, 2008, 6:03:38 AM4/30/08
to

"Martin Meyer" <mme...@nurfuerspam.de> schrieb im Newsbeitrag
news:nure14tllvhauu5fi...@4ax.com...

> Hi Sascha,
>
> On Tue, 29 Apr 2008 20:09:40 +0200, "Sascha Trowitzsch" <n...@moss-soft.de>
> wrote:
>
>>[...]
>>Es hört sich bei dir aber so an, als wäre es blöd von MS, allen Versionen die
>>gleiche CLSID zu geben.
>
> Ja ich finde es auch blöd ;-)
>
> Und ehrlich gesagt, würde ich es auch schlichtweg als Bug bezeichnen,
> wenn die Klasse XX anfordere, aber kommentarlos die Klasse XY als Instanz
> untergeschoben bekommen - auch wenn der Bug hier 'by Design' ist.

Stimmt doch nicht! Du willst als Klasse eine Access.Application und bekommst sie
in jedem Fall auch!
Was hat die Klasse mit ihrer *Implementation* zu tun? Du bekommst lediglich
unterschiedliche Implementationen der gleichen Klasse.

>> Hast du dir die Konsequenz
>>überlegt, was wäre, wenn alle Versionen unterschiedliche CLSIDs hätten?
>
> Kann ich Dir nicht sagen, ob das nicht auch anders lösen könnte, weil ich
> einfach zu wenig über das Konzept weiss. Ich habe irgendwie das Gefühl,
> dass dieser Weg zur Kompatibilität über die gleiche CLSID mit der "groben
> Kelle" gemacht ist.

> ...


>>Dann würde eine Menge Kompatbilität flöten gehen!
>
> In diesem Fall zB. welche Kompatibilität speziell?
> (Frage ist keine Provokation, sondern aus Unwissenheit und aufrichtigem
> Interesse).
> Bei anderen Produkten kann ich auch diverse Programm-Versionen völlig
> ohne gegenseitige Beeinflussung parallel nutzen.

Und sind die auch automationsfähig?

Wenn du unterschiedliche Type Library-CLSIDs oder auch Application-CLSIDs für
die einzelnen Versionen hättest, dann würde beim Öffnen einer MDB in einer
anderen Access-Version jedesmal die COM-Kompatibilität des VBA-Projekts flöten
gehen. Im Mindestens müsste es dann dekompilert werden, was ja auch passiert,
wenn du eine A97-MDB in A200x öffnest.
Im kompilierten VBA-Projekt sind ja die Verweise auf die Klassen bzw. deren
Interface-Identifiers fest reinkompiliert. Beim Ausführen eines Codes muss nicht
mehr in der Typelibrary nachgeschaut werden (QueryInterface), wo die
VTable-Einsprungspunkte liegen. Das ist ja das Prinzip von Early Binding.
Wären die Interface-CLSIDs nicht identisch, dann würde etwa eine in A2003
erstellte MDB unter A2000 nicht mehr so einfach zu öffnen sein - die
Verweisversion könnte nicht mehr heruntergesetzt werden, wie das aktuell
automatisch passiert, weil VBA nicht wissen kann, ob die Klassen noch kompatibel
sind bzw. zur von Access intern selbst verwendeten VBA- und Access-Bibliothek
passen.
Ich finde das gut und sehe hier keinen "Bug by design". Ohne die Kompatibilität
der Type Libraries würde es drunter und drüber gehen, wenn eine MDB in
verschiedenen Access-Versionen verwendet würde.

Ciao, Sascha


Martin Meyer

unread,
Apr 30, 2008, 12:10:39 PM4/30/08
to
Hallo Peter,

on Wed, 30 Apr 2008 03:12:20 +0200, Peter Doering <nos...@doering.org>
wrote:

> [...]


>Nachdem ich das in der Vergangenheit fuer Access immer wieder mal
>erfolgreich eingesetzt hatte, hab ich das jetzt nochmal in einer VM in
>allen Kombinationen getestet.

Du hättest mir auch einfach glauben können, statt Dir die Nacht mit
Aufsetzen der virtuellen Testsysteme um die Ohren zu hauen ;-)
Aber da Du Dir schon die Mühe gemacht hast: Wie haben sich Deine
Acc-Vollversionen unter HK_CLASSES_ROOT\Licenses\<CLSID>\
eingetragen?

>Zunaechst, meine Erinnerung war korrekt, was
>Access angeht, und zwar mit den Versionen A97 und A02. Folgende Prozedur
>funktioniert, egal ob man sie unter A97 oder A02 ausfuehrt:
>
>Sub TestAutomation()

> [... CODE ..]


>Ergebnis: A97 und A02 wurde jeweils korrekt geoeffnet, egal wo die Prozedur
>lief. Damit war's das aber auch. :-(

>Die gleiche Prozedur um Access.Application.11 erweitert hat das Objekt
>jeweils in der Version erstellt, in der die Prozedur ausgefuehrt wurde,
>bzw. von A97 aus die, die vor A97 zuletzt gestartet worden war. Nur A97
>wurde immer verlaesslich erstellt.

Klar. Hier hatte MS dem A97 auch noch eine eigene CLSID spendiert, alle
Versionen ab A00 haben die gleiche gemeinsame.
(Hmmm, hier gab' es offenbar keine Kompatibilitäts-Bedenken bei der
Verwendung einer neuen ID).

Besonders ärgerlich an dieser Sache ist, die Tatsache, dass ein Code
wie der von Dir angeführte nicht mehr funktioniert, wenn Du eine höhere
RT auf ein System istallierst. Hat ein Kunde zB. seine A00-Vollversion
installiert und nutzt Software mit Automatisierung nach obigen Muster und
Du schwartest ihm eine A0X-Runtime für Deine Acc-Applikation drauf,
dann sabotierst Du sein System dadurch. Ich meine jetzt nicht die
Klick-auf-mdb-Problematik, für die der Kunde idR. zwar auch kein
Verständnis aufbringt, sondern vielmehr den Umstand, dass seine Soft
mit Automatisierung nun nicht mehr funktioniert.

Ein CreateObject("Access.Application.9") liefert nun eine Instanz der
neueren A0X-Runtime, bzw. liefert diese grade nicht mehr, wegen der
bekannten Automatisierungsbeschränkung von RTs, dafür aber einen
Automatisierungs-Fehler :(

>Bei Word und Excel war das Ergebnis leider noch eindeutiger, es wurden
>immer .11 gestartet, egal von wo, egal welche Nr.

Auch klar, weil bei Word97 bereits die gleiche CLSID benutzt wurde, wie
in allen Folgeversionen.

Gruß,
Martin

PS.: Ahh, ich seh' grad am eintreffenden Posting von Sascha, das er dies
schon ausgeführt hatte - aber egal, jetzt hab' ich's getippt, dann sende
ich's auch ;)

Martin Meyer

unread,
Apr 30, 2008, 12:56:04 PM4/30/08
to
Hallo Sascha,

vielen Dank für Deine Ausführungen.

on Wed, 30 Apr 2008 12:03:38 +0200, "Sascha Trowitzsch" <n...@moss-soft.de>
wrote:

>


>"Martin Meyer" <mme...@nurfuerspam.de> schrieb im Newsbeitrag
>news:nure14tllvhauu5fi...@4ax.com...

>> [...]


>> Und ehrlich gesagt, würde ich es auch schlichtweg als Bug bezeichnen,
>> wenn die Klasse XX anfordere, aber kommentarlos die Klasse XY als Instanz
>> untergeschoben bekommen - auch wenn der Bug hier 'by Design' ist.

>Stimmt doch nicht! Du willst als Klasse eine Access.Application und bekommst sie
>in jedem Fall auch!
>Was hat die Klasse mit ihrer *Implementation* zu tun? Du bekommst lediglich
>unterschiedliche Implementationen der gleichen Klasse.

Ok, ich möchte hier keine Wortklauberei mit Dir beginnen, jedenfalls
bekomme ich nicht das was ich anforderte:
"Ich hätte gern einen Whisky, Jim Bean" ... "Das ist kein Jim Bean!" ...
"Doch. Sie hatten Whisky bestellt - Sie haben einen Whisky bekommen."
Das fändest Du korrekt? ;-)

Und im Beispiel der Parallelinstallation einer A00-Vollversion und einer
A02-RT bekomme ich bei Anforderung von Acc.App.9 garnix ... oder doch:
einen Automatisierungsfehler :(


>Wenn du unterschiedliche Type Library-CLSIDs oder auch Application-CLSIDs für
>die einzelnen Versionen hättest, dann würde beim Öffnen einer MDB in einer
>anderen Access-Version jedesmal die COM-Kompatibilität des VBA-Projekts flöten
>gehen.

Es ist IMHO nix dagegen einzuwenden, dass eine Datei nur mit der
passenden Programmversion (in vollem Umfang) harmoniert.
Solange es eine Portierungsmöglichkeit in die neue Version gibt und/oder
die Versionen parallel vorrätig gehalten werden können (also voll
funktionsfähig, nicht systemsabotierend) erst recht nicht.
Wenn ich mir ein neues Automodell zulege, kann ich auch nicht erwarten,
dass ich sämtliches Zubehör vom Vorgängermodell in vollem Umfang
weiternutzen kann.

> Im Mindestens müsste es dann dekompilert werden, was ja auch passiert,
>wenn du eine A97-MDB in A200x öffnest.

So what? Sehe ich nicht als so große Komforteinbuße. Dauert einen
Augenblick länger, anschließend habe ich die Möglichkeit das Teil im
passenden Format wegzuspeichern oder auch nicht. Das würde ich auch beim
Öffnen einer A00-Datei mit A02 usw .. akzeptieren.

>Im kompilierten VBA-Projekt sind ja die Verweise auf die Klassen bzw. deren
>Interface-Identifiers fest reinkompiliert. Beim Ausführen eines Codes muss nicht
>mehr in der Typelibrary nachgeschaut werden (QueryInterface), wo die
>VTable-Einsprungspunkte liegen.

Ja ok, das leuchtet mir ein.

>Wären die Interface-CLSIDs nicht identisch, dann würde etwa eine in A2003
>erstellte MDB unter A2000 nicht mehr so einfach zu öffnen sein -

"Einfach" wahrscheinlich nicht. Ist aber AFAIR eh nicht zu öffnen, außer
sie wurde im A00-Format abgespeichert. Aber ich hatte ja bereits
gemutmaßt, es handele sich bei der gleichen-CLSID-Lösung um eine
(sich's) einfach gemachte Lösung ;-)

>die Verweisversion könnte nicht mehr heruntergesetzt werden, wie das aktuell
>automatisch passiert, weil VBA nicht wissen kann, ob die Klassen noch kompatibel
>sind bzw. zur von Access intern selbst verwendeten VBA- und Access-Bibliothek
>passen.

Für das Szenario "neue MDB mit alter Anwendung öffnen" sehe ich das ein,
aber wer verlangt das sowas funktionieren muss (tut's ja auch bei dieser
"Lösung" mit identischer CLSID nur halbgar).
Ist diese Kompatibilität (also dass zB. aus einer neuen Version ein altes
Dateiformat erzeugt werden kann) denn notwendigerweise daran gebunden,
dass alle Versionen unter gleicher Flagge segeln? Ist nicht vielleicht
nicht auch Disziplin in Richtung Beachtung der Abwärtskompatibilität bei
der Weiterentwicklung von Versionen ausreichend?

Davon abgesehen, wäre *mir* die oben geschilderte Kompatibilität zwischen
A97 und A0x (mit unterschiedlichen CLSIDs) ausreichend
(wobei ich allerdings vermute, dass es nicht zwingend erforderlich wäre,
dass sich jede Version erstmal ins CurVer eintragen müsste?).

Peter Doering

unread,
Apr 30, 2008, 6:00:13 PM4/30/08
to
Hallo Martin,

Martin Meyer wrote:


> Peter Doering wrote:
>
>> [...]
>>Nachdem ich das in der Vergangenheit fuer Access immer wieder mal
>>erfolgreich eingesetzt hatte, hab ich das jetzt nochmal in einer VM in
>>allen Kombinationen getestet.
>
> Du hättest mir auch einfach glauben können,

Nee, wie geschrieben, ich hatte es funktionierend in Erinnerung. Und in
meiner damaligen Kombination funktioniet es immer noch.



> statt Dir die Nacht mit Aufsetzen der virtuellen Testsysteme um die Ohren
> zu hauen ;-)

Nett, dass du mir derartigen Enthusiasmus unterstellst, aber die VM gab's
schon, ich hatte vorher nur keine Zeit, sie anzuwerfen. ;-)

> Aber da Du Dir schon die Mühe gemacht hast: Wie haben sich Deine
> Acc-Vollversionen unter HK_CLASSES_ROOT\Licenses\<CLSID>\
> eingetragen?

HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\10.0\Retail
HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\11.0\Retail
bzw.
HK_CLASSES_ROOT\Licenses\<CLSID-A97>\Retail


> [...]


> Besonders ärgerlich an dieser Sache ist, die Tatsache, dass ein Code
> wie der von Dir angeführte nicht mehr funktioniert, wenn Du eine höhere

> RT auf ein System istallierst. [...]

Jo, ist leider so. Einer der Gruende, warum ich um die Runtime einen Bogen
mache.

Martin Meyer

unread,
May 1, 2008, 6:29:55 AM5/1/08
to
Hallo Peter,

on Thu, 1 May 2008 00:00:13 +0200, Peter Doering <nos...@doering.org>
wrote:

>[...]


>Nett, dass du mir derartigen Enthusiasmus unterstellst, aber die VM gab's
>schon, ich hatte vorher nur keine Zeit, sie anzuwerfen. ;-)

Ich dachte nur .. wegen des Zeitstempels vom Posting: 03:12 a.m.

>> Aber da Du Dir schon die Mühe gemacht hast: Wie haben sich Deine
>> Acc-Vollversionen unter HK_CLASSES_ROOT\Licenses\<CLSID>\
>> eingetragen?
>
>HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\10.0\Retail
>HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\11.0\Retail
>bzw.
>HK_CLASSES_ROOT\Licenses\<CLSID-A97>\Retail

Ah ja, danke!
Also Vollversionen scheinen immer als 'Retail' zu erscheinen.
Ich werde dies dann mal als Kriterium für das Vorliegen einer VW nehmen.
Wenn ich nur sicher wüßte, dass es nicht auch anders registrierte VW
gibt, wäre mir wohler.

Ein A00 wird dann wahrscheinlich direkt
HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\Retail
auftauchen (hab grad leider keinen Rechner mit A00 zur Hand).

>> Besonders ärgerlich an dieser Sache ist, die Tatsache, dass ein Code
>> wie der von Dir angeführte nicht mehr funktioniert, wenn Du eine höhere
>> RT auf ein System istallierst. [...]
>
>Jo, ist leider so.

Eigentlich sabotiert man ein funktionierendes System durch Installation
so einer Runtime - eine RT dürfte sich nicht als automatisierbare
Komponente registrieren, weil sie nicht vollwertig automatisierbar ist.
Man könnte dies auch als Bug bezeichnen.

THX & Gruß,
Martin

Peter Doering

unread,
May 1, 2008, 3:26:20 PM5/1/08
to
Hallo Martin,

Martin Meyer wrote:


> Peter Doering wrote:
>
>>[...]
>>Nett, dass du mir derartigen Enthusiasmus unterstellst, aber die VM gab's
>>schon, ich hatte vorher nur keine Zeit, sie anzuwerfen. ;-)
>
> Ich dachte nur .. wegen des Zeitstempels vom Posting: 03:12 a.m.

Jo, mein Tagesablauf ist etwas aus der Reihe ;-)

>>> Aber da Du Dir schon die Mühe gemacht hast: Wie haben sich Deine
>>> Acc-Vollversionen unter HK_CLASSES_ROOT\Licenses\<CLSID>\
>>> eingetragen?
>>
>>HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\10.0\Retail
>>HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\11.0\Retail
>>bzw.
>>HK_CLASSES_ROOT\Licenses\<CLSID-A97>\Retail
>

> Also Vollversionen scheinen immer als 'Retail' zu erscheinen.

Jo.

> Ich werde dies dann mal als Kriterium für das Vorliegen einer VW nehmen.
> Wenn ich nur sicher wüßte, dass es nicht auch anders registrierte VW
> gibt, wäre mir wohler.
>
> Ein A00 wird dann wahrscheinlich direkt
> HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\Retail
> auftauchen (hab grad leider keinen Rechner mit A00 zur Hand).

Ich hab auch kein A00 mehr, aber nachdem das Schluesselkonzept auch bei
Stand-Alone-Installationen beibehalten wird, denke ich, dass der Schluessel
fuer A00 nach dem gleichen Prinzip erstellt wird, also:

HK_CLASSES_ROOT\Licenses\<CLSID-A0x>\9.0\Retail

Reply all
Reply to author
Forward
0 new messages