Office: (Office 2010) SEPA Sammelüberweisung per VBA

Hallo,

seit einiger Zeit suche ich für eine von mir entwickelte Access-Datenbank (ACCESS 2010) einen VBA-Code, den ich als Modul integrieren kann. Nach einiger Korrespondenz mit dem Entwickler von sevDTA (Tools & Components · Entwicklertools · sevDTA 2.0) hat sich herausgestellt, dass dieser Code meine 64bit-Version von Access nicht unterstützt. Kann mir jemand einen Tipp geben, wo es einen solchen Code gibt? - Das wäre recht nett.

Gruß,
R.Obert

:)

 

Dieter Otter hat seine Antwort sicher anders formuliert als Du in Deinem Beitrag. Der Code seiner 32Bit-Lösung wäre sicherlich an 64Bit anpassbar.

Allerdings werden generell noch sehr wenig Komponenten für 64Bit erzeugt, so dass umgedreht auch wahrscheinlich kein lukrativer Markt für derlei besteht.

Du könntest eine Anfrage stellen, ob Du eine 64Bit-Version der DLL bzw. alternativ den Quellcode erhalten könntest, dann allerdings mit einem deutlich höherem Preisangebot als 179 €.

 

Dieter Otter schreibt mir: "Eine 64-Bit Version der DLL für den Einsatz unter MS-Access wird es nicht geben."

Ich bin einigermaßen ratlos. Soll ich auf einen älteren Rechner umsteigen, dort Access neu installieren, um dann unter 32bit weiter zu entwickeln? Oder kann man das Access 2010 dazu bringen mit 32bit zu arbeiten?

Danke für die Antwort!

 

Microsoft

Also: Wenn Du potentiell Fremdkomponenten verwenden willst oder gar darauf angewiesen bist, verwende die 32Bit-Version von Office. Diese läuft auch auf einem 64Bit-Win, also auf einem aktuellen Rechner.

 

Danke für die Antwort.

Um der größeren Kompatibilität willen dürfte es also sinnvoll sein, wenn ich die 64bit-Version meines Access2010 durch die 32bit-Version ersetze.

Muss ich dazu das Access deinstallieren, gar das komplette Office2010 deinstallieren und dann die 32bit-Version neu installieren? Oder geht das auch einfacher? Und vor allem: Hoffentlich geht dann meine Datenbank noch??!!

Ich hab leider keine Erfahrung mit diesen Dingen ...

Gruß,
R. Obert

 

64Bit und 32Bit nebeneinander geht nicht. Also Office komplett deinstallieren und andere Version neu installieren.

Zur Datenbank kann ich mangels Erfahrung mit 64Bit nichts sagen. Allerdings entsteht ja bei 64Bit keine völlig neue andersartig gestaltete Datenbank (oder ein anderes Dokument), sondern 64Bit erhöht den Adressierungsbereich von Speicher und somit Gültigkeitsbereiche von Variablen. Um so weniger solche neuen Features inklusive Zugriffe auf Win-API's verwendet wurden, um so weniger Probleme würde ich bei der Übernahme nach 32Bit erwarten.

Falls der Versuch nicht klappt und ein Neuaufbau sehr aufwändig ist (bzw. schon vorbeugend):
Man kann mit der Methode SaveAsText seine Accessobjekte, genauer deren Definitionen, in Textdateien exportieren. Mit LoadFromText wäre dann ein Reimport umzusetzen.

Wenn man also testweise ein gleiches Formular aus 64Bit-Access und 32Bit-Access exportiert und die Unterschiede erkennt, kann man dann umgedreht aus 64Bit-Formularen 32Bit-Formulare machen (per intelligenter Textverarbeitung).

 

Bei mir schon.
Auf zwei Rechnern, die nebeneinander stehen. *mrcool

Neben den von Eberhard angesprochenen Zugriffen, die unter 64Bit mit PtrSafe deklariert werden müssen, nerven beim Wechsel der Plattform immer mal wieder die über Verweise eingebundenen Bibliotheken.

Hinsichtlich Datenbankstrukturen hatte ich noch keine Probleme.

Aber im Hinblick auf den produktiven Einsatz habe ich entweder 32- oder 64-Bit Lösungen, je nachdem, was beim Kunden vorliegt.

 

\@Hans-Christian:
Ich korrigiere: MITEINANDER

 

Nun denn. Danke für Eure Antworten.

 

Es ist durchaus moeglich Access als 32bit und 64bit auf dem gleichen Rechner zu verwenden - jedoch nicht die gleiche Version. (Und ein wenig tricky ist das mit mehreren Access-Versionen ja schon immer gewesen.)

Bei mir laeuft z.B. neben der 64bit-Version von Acc2010 auch noch die alte 32bit-Version von Acc97. Beisst sich nicht....

Auch kann ich in Acc97 eine MDB erstellen, darin eine Tabelle anlegen, diese MDB anschliessend in Acc2010 oeffnen und in eine ACCDB konvertieren. Dabei bleibt die ACCDB aber 32bit und wird nicht auf 64bit umgestellt.
Die DB selbst muss also bereits als 32- oder 64bit-Version erstellt worden sein. Die Weiterbearbeitung kann dann durchaus in Acc2010 erfolgen.

Und selbst wenn man aus der konvertierten ACCDB anschliessend eine Executable (ACCDE fuer die Runtime-Version) erzeugt, dann wird selbst auf einem 64bit-Betriebssystem die Runtime gefordert, die zur ACCDE passt. Ist die Ausgangsdatenbankanwendung 32bit, wird dementsprechend die 32bit-Runtime benoetigt, bei einer 64bit-Ausgangsdatenbank eben die 64bit-Runtime.

Rein technisch kann man also auch in einem 64bit-Access eine 32bit-DB bearbeiten und somit auch 32bit-DLLs verwenden. (Was ich in einem aktuellen Projekt auch selbst mache - lustigerweise mit DTA, welches ab naechsten Monat um SEPA ergaenzt werden soll.)
Die Zielrechner sind dabei zum Teil noch mit XP Professional ausgestattet, zum Teil aber schon mit Windows 7 in Betrieb. Auf beiden Plattformen laeuft die 32bit-Runtime von Acc2010 mit der gleichen ACCDE absolut problemlos.

 

Ich war schon ganz desillusioniert und hab mich mit dem Gedanken einer Neuinstallation getragen.

ABER DAS SCHEINT JA WIRKLICH DIE LÖSUNG ZU SEIN!

Meine Datenbank wurde nämlich von 2003 auf 2010 konvertiert*Smilie

Jetzt aber noch die eigentlich spannende Frage: WIE stellst Du auf SEPA um?

In meiner Datenbank habe ich bereits das alte DTA implementiert. Aber dummerweise läuft die Prozedur über Verwendung von Excel. Da ich aber nicht davon ausgehen kann, dass jemand, der meine Datenbank als Runtime installiert hat, auch Excel hat, muss ich einen VBA-Code schreiben (lassen), der die Sammelüberweisungs-Tabelle in den SEPA-Code umsetzt. Gibt es da sonst noch eine Lösung?

Gruß,
R.Obert

 

Die Sache mit Excel verstehe ich eher nicht ... sowohl DTA als auch jedes andere Exportformat kommt bei mir zuerst in temporäre lokale Access Tabellen und von dort in die passende Exportdatei.

 

Die wirklich spannende Frage ist doch, wie weit SEPA tatsaechlich zur Anwendung kommt....

SEPA kommt doch grundsaetzlich erst einmal nur im Austausch der Bankinformationen zum Tragen. Es werden nicht mehr die bisher verwendeten Informationen wie Kontonummer und Bankleitzahl verwendet, sondern die internationalen Daten wie IBAN/BIC etc.
Weiterhin interessiert SEPA ein Unternehmen doch nur dann, wenn es von seinen Auftraggebern Einzugsermaechtigungen/Abbuchungsauftraege vorliegen hat, da hierbei die vorgeschriebenen Fristen fuer die Rechnungslegung etc. VOR der Abbuchung eingehalten werden muessen.
Existieren keine Abbuchungen/Einzugsermaechtigungen, ist SEPA ausser bei den Bankverbindungsdaten absolut uninteressant.....

Das hier verwendete DTA-Modul wurde mit 9 Tabellen, mehreren Formularen, diversen Berichten und offenem Quellcode zugekauft - woher das Teil stammt, kann ich im Moment nicht mal sagen, da ich noch an anderen Baustellen in der DB arbeite und mich darum noch nicht weiter gekuemmert habe. Aber so wie ich das grob beurteile, ist es nicht sonderlich schwer, die Formulare/Berichte/Tabellen/Codes anzupassen. Die Funktionsaufrufe der zugehoerigen DLL duerften da wenig ins Gewicht fallen.

Ja, eine Export-Schnittstelle nach Excel ist darin auch enthalten. Die wird aber durch die innerhalb der DB vorhandenen Berichte gar nicht benoetigt.

 

Nunja, sagen wir mal so, spätestens ab 1. Feb. 2014 interessiert es jedes Unternehmen das aktuell DTA einsetzt, ungeachtet ob Lastschriften oder Zahlungen angewiesen werden. Inwieweit die sonst üblichen Standard-Überweisungen mittels Kto/BLZ auch unter die erweiterte Übergangsfrist (z.B. für ELV) bis 2016 fallen weiß ich nicht.

http://www.bundesbank.de/Redaktion/D...ler_stand.html