Nabend, ich versuche gerade in C# Daten aus einer Excel Tabelle auszulesen, was im Prinzip auch kein wirkliches Problem darstellt: 1. In HKEY_CLASSES_ROOT nach einem entsprechenden Provider suchen (Microsoft.ACE.OLEDB.xx.0). 2. Dann den entsprechenden Connection String für die OleDbConnection zusammenbasteln. 3. Mit SELECT Spalte auf das entsprechende Tabellenblatt, was man sich eventuell übers Schema holt, die Abfrage machen und per ExecuteReader auslesen. Nur wie zur Hölle bekomme ich heraus ob der entsprechende Provider in 32 oder in 64 Bit installiert ist? Und wie greife ich dann von einer 32 Bit Anwendung auf einen 64 Bit Provider oder umgekehrt zu? Habe momentan einfach 2 weitere Konsolen Anwendungen gebaut, in 32 und 64 Bit, die den Import übernehmen und dann per Console ausgeben. In der Hauptanwendung werden diese dann per Process Start und RedirectStandardOutput, CreateNoWindow von mir nacheinander gestartet und per StandardOutput.ReadLine() ausgelesen; was auch funktioniert aber alles andere als elegant ist. Klar ich könnte über COM-Sockets, Window Messages oder auch über irgendwelche memory mapped Files das Ganze lösen, nur müsste das doch irgendwie besser gehen, also der Zugriff auf die entsprechende Provider-Variante. Achja, das Konvertieren in irgendein anderes Format, z.B. csv scheidet leider aus.
:
Bearbeitet durch User
Wer braucht wirklich 64 bit Excel ? Außer hipster die meinen 64 Bit hört sich besser an. Wenn das wirklich jemand benötigt der nutzt vorher was anderes für seine Daten z.B. eine richtige Datenbank. Warum nicht einfach die Registry abfragen?
:
Bearbeitet durch User
Chris K. schrieb: > Wer braucht wirklich 64 bit Excel ? Das ist mir absolut egal, nur manche haben es eben. Aber mein eigentliches Problem ist eh ein anderes. Meine Anwendung ist zwangsweise auf 64 Bit weil ich zig 64 Bit Dll importiere, von denen mir auch manche überhaupt nicht in 32 Bit vorliegen, sonst hätte ich eh zwei Versionen gebaut. > Wenn das wirklich jemand benötigt der nutzt vorher was anderes für seine > Daten z.B. eine richtige Datenbank. Auch das ist nicht der Punkt. > Warum nicht einfach die Registry abfragen? Und bitte wo da?
:
Bearbeitet durch User
Do I have Microsoft Excel 64 bit edition installed?
Answer / Solution
Please follow the KCS Knowledge Article guidelines to properly format
your answer/solution
***WARNING! The following instructions require you to open the Windows
Registry Editor. Changing the Windows Registry could render your PC
useless. We highly recommend that you backup your Registry before
continuing!***
Start > Run > Regedit
Expand HKEY_LOCAL_MACHINE\Software\Microsoft\Office\xx.y\Outlook
where xx.y is a version number, typically 10.0 through 20.0. If this
key does not exist then it is likely registered under Wow6432Node, which
means it is a 32-bit version.
Look at the value in the key called Bitness. This value should be
either x86 (32-bit) or x64 (64-bit).
Schlechter Tag und google defekt.
Chris K. schrieb: > Do I have Microsoft Excel 64 bit edition installed? > Schlechter Tag und google defekt. Nö, nur ist Excel nicht verantwortlich dafür ob und welchen OLEDB Provider es gibt, willst du nochmal versuchen?
Ist zwar VB sollte man aber umschreiben können. https://administrator.de/tutorial/herausfinden-ob-eine-microsoft-office-anwendung-installiert-ist-mit-vbs-bzw-vba-204951.html Hat bei mir funktioniert als ich das mal Testweise ausprobiert habe. Leider wurde das Projekt gestoppt. Hab aber keine Ahnung ob es mit moderneren Versionen funktioniert.
Die alternative ist. Du rufst einfach ein Provider auf, und fängst den Fehler ab. Mache ich ja auch.
Schlaumaier schrieb: > Ist zwar VB sollte man aber umschreiben können. > > https://administrator.de/tutorial/herausfinden-ob-eine-microsoft-office-anwendung-installiert-ist-mit-vbs-bzw-vba-204951.html > > Hat bei mir funktioniert als ich das mal Testweise ausprobiert habe. > Leider wurde das Projekt gestoppt. > > Hab aber keine Ahnung ob es mit moderneren Versionen funktioniert. -.- Du hast mir gerade noch gefehlt. An welcher Stelle dieses dumpfen Skriptes steht ob DER PROVIDER (nicht irgendeine Anwendung) in 32 oder 64 Bit installiert ist? Und wo steht welche Softwarekomponente welchen OLEDB Provider mitbringt? Also bitte lass es einfach sein und troll woanders. Und wo wir gerade dabei sind, antworte bitte NIE WIEDER auf einen meiner Threads (oder einen anderen).
Schlaumaier schrieb: > Die alternative ist. > > Du rufst einfach ein Provider auf, und fängst den Fehler ab. > > Mache ich ja auch. Wenn du nur ansatzweise lesen könntest wäre dir nicht entgangen, dass ich dafür bereits zwei Konsolen Anwendungen habe (von denen eine dann das richtige Ergebnis liefert), wobei natürlich bei der unpassenden der Fehler abgefangen wird. Aber das kann es doch echt nicht sein.
32 bit werden nach Program Files (x86) installiert 64 bit nach Program Files dann nach vorhanden sein checken .... Fehler einfach abfangen... Aber warum der Weg über OleDbConnection? Altlasten oder aktuellen Prozess modernisieren anstatt sauber neu zu gestalten und verarbeiten?
Chris K. schrieb: > 32 bit werden nach Program Files (x86) installiert > 64 bit nach Program Files > > dann nach vorhanden sein checken .... > Fehler einfach abfangen... Ich suche nach wie vor eine Möglichkeit festzustellen ob DER PROVIDER in 32 oder 64 Bit ist, nicht irgendwelche Anwendungen. > Aber warum der Weg über OleDbConnection? > Altlasten oder aktuellen Prozess modernisieren anstatt sauber neu zu > gestalten und verarbeiten? Vorgabe ist, es müssen Daten aus einem Excelsheet mit bekanntem Aufbau importiert werden, zusätzliche Software ist nicht zulässig, nicht mehr und nicht weniger, Spielraum NULL.
Check wo und welcher Provider installiert ist dann weisst du welcher installiert ist. File Vorhanden dann ..... OleDB Object Linking and Embedding, Database Also warum nicht gleich ne richtige DB anstatt den Weg über OleDB zum Excel File. Das Design und das hängenbleiben an Excel Files wird in Zukunft mehr kosten verursachen als das Prinzip jetzt neu zu denken und neu zu gestalten.
Chris K. schrieb: > Check wo und welcher Provider installiert ist dann weisst du welcher > installiert ist. > File Vorhanden dann ..... Es ist jetzt nicht bekannt wie die jeweiligen Umgebungen letztlich aussehen, nur das ein entsprechender Provider vorhanden sein wird ist Vorgabe. > OleDB Object Linking and Embedding, Database > Also warum nicht gleich ne richtige DB anstatt den Weg über OleDB zum > Excel File. > > Das Design und das hängenbleiben an Excel Files wird in Zukunft mehr > kosten verursachen als das Prinzip jetzt neu zu denken und neu zu > gestalten. Das Excel File ist aber vorgegeben, daran ist nicht zu rütteln, ob es mir gefällt ist nicht relevant, es ist so umzusetzen und nicht anders. Nicht mit einer Datenbank, nicht mit einer CSV oder sonstwas.
:
Bearbeitet durch User
Tim T. schrieb: > Das Excel File ist aber vorgegeben, daran ist nicht zu rütteln, ob es > mir gefällt ist nicht relevant, es ist so umzusetzen und nicht anders. Excel Files können oft seltsame Zustände annehmen. Ist die Datei zu sehr angewachsen ? Den Fall hatte ich auch mal alte formatierungen ... löschen usw. und schon wurde das File von ca. 5 Mb auf nur noch 40 kB gecleant. Viel Spaß noch mit dem Excel File das zwar als einziges File Format über alle Jahre nicht verändert hat aber noch immer alle Schwächen seit 20 Jahren mitschleppt. Plain Text bzw. csv oder Datenbank wäre noch immer viel besser zu verarbeiten.
:
Bearbeitet durch User
Chris K. schrieb: > Tim T. schrieb: >> Das Excel File ist aber vorgegeben, daran ist nicht zu rütteln, ob es >> mir gefällt ist nicht relevant, es ist so umzusetzen und nicht anders. > > Excel Files können oft seltsame Zustände annehmen. > > Ist die Datei zu sehr angewachsen ? > Den Fall hatte ich auch mal alte formatierungen ... löschen usw. und > schon wurde das File von ca. 5 Mb auf nur noch 40 kB gecleant. Nein, es werden maximal 100 Zeilen sein und immer eine andere Datei. Die Dateien kommen von Extern aus einem definierten Prozess, mit genau definierter Struktur, den keiner jemals wieder anfassen wird. > > Viel Spaß noch mit dem Excel File das zwar als einziges File Format über > alle Jahre nicht verändert hat aber noch immer alle Schwächen seit 20 > Jahren mitschleppt. > > Plain Text bzw. csv oder Datenbank wäre noch immer viel besser zu > verarbeiten. Klar, aber wie gesagt die Strukturen davor sind gesetzt und ich könnte mir zig Varianten ausdenken mit denen es besser gehen würde. Bin unter anderem auch am überlegen die xlsx Dateien einfach zu entzippen und mit einem eigenen Modul die entsprechenden Daten aus dem xml zu lesen. Wollte das zwar vermeiden aber es scheint als könnte das letztlich doch der einfachere Weg sein.
Tim T. schrieb: > Nein, es werden maximal 100 Zeilen sein und immer eine andere Datei. > Die Dateien kommen von Extern aus einem definierten Prozess, mit genau > definierter Struktur, den keiner jemals wieder anfassen wird. > >> >> Viel Spaß noch mit dem Excel File das zwar als einziges File Format über >> alle Jahre nicht verändert hat aber noch immer alle Schwächen seit 20 >> Jahren mitschleppt. >> >> Plain Text bzw. csv oder Datenbank wäre noch immer viel besser zu >> verarbeiten. > > Klar, aber wie gesagt die Strukturen davor sind gesetzt und ich könnte > mir zig Varianten ausdenken mit denen es besser gehen würde. > Bin unter anderem auch am überlegen die xlsx Dateien einfach zu > entzippen und mit einem eigenen Modul die entsprechenden Daten aus dem > xml zu lesen. Wollte das zwar vermeiden aber es scheint als könnte das > letztlich doch der einfachere Weg sein. Du Armer musst dich einem schlechten Export deines Kunden beugen. Warum auch immer die Externen das excel Format gewählt haben, vielleicht nur abhängig oder zu wenig Kenntniss um alternativen Formaten. Aber es scheint so als du einen neuen einfacheren Weg gefunden hast. Software ist Soft Ware und bleibt immer weich ;-)
Hast du Libraries wie EPPlus in Betracht gezogen? Damit geht es viel sauberer.
Ich frage mich gerade was ein Excel-File mit einer Datenbank zu tun hat. Ein Excel-File auslesen mache ich via Interop. . Und das ist nur ne DLL die in meinen Verzeichnis hockt. Da Interop aber eine Excel-Installation voraussetzt, prüfe ich mit einen Start-Prg. das vorher nach. Was die Datenbank angeht. Wenn sie vorgeschrieben ist, reicht ein Telefon-Anruf. Dann weiß ich welche Version installiert ist, und ich rufe den passenden Treiber auf. Schreibe in den nachtrag des Vertrages das diese DB zwingend erforderlich ist. Mit Updates kann man auch Geld verdienen. ;) Und den Provider austauschen ist schnell verdientes Geld. Wenn sie nicht vorgeschrieben ist, bestimme ich sie und nutze eine Norm-DB also Excel o. mit Runtime-Installation bzw. DLL eine SQL-Version. Weshalb mein Link da richtig war. Denn dann kann ich feststellen welche Version von Access auf den Rechner ist, falls ich mich für MDB(Access-Format) entscheide. Davon abgesehen, wenn man ein Start-Modul nutzt kann man eine Globale Variable festlegen. Deren Status schreibt man in eine Ini-Datei oder Registry. Im Start-Prg. liest man die aus, und übergibt sie an das Haupt-Prg. . Da schreibt man eine if-then Anweisung nach den Motto. If bit_status = 32 bit then den_provider else den_ anderen Wenn das prg sauber beendet wurde, dann schreibt man den Bit_status wieder in die Reg bzw. ini. Somit stellt sich das Programm selbstständig richtig ein. Ähnliches machen übrigens viele Programme bei Sprachen wechsel.
Schlaumaier schrieb: > Ich frage mich gerade was ein Excel-File mit einer Datenbank zu tun hat. > > Ein Excel-File auslesen mache ich via Interop. . Und das ist nur ne DLL > die in meinen Verzeichnis hockt. Da Interop aber eine > Excel-Installation voraussetzt, prüfe ich mit einen Start-Prg. das > vorher nach. Excel kann aber nicht immer als gegeben vorausgesetzt werden, also Sackgasse. > Was die Datenbank angeht. > > Wenn sie vorgeschrieben ist, reicht ein Telefon-Anruf. Dann weiß ich > welche Version installiert ist, und ich rufe den passenden Treiber auf. > Schreibe in den nachtrag des Vertrages das diese DB zwingend > erforderlich ist. Du scheinst es einfach nicht zu verstehen, es gibt keine Möglichkeit an den Gegebenheiten noch etwas zu verändern. Der Drops ist gelutscht. > Mit Updates kann man auch Geld verdienen. ;) Und den Provider > austauschen ist schnell verdientes Geld. > > Wenn sie nicht vorgeschrieben ist, bestimme ich sie und nutze eine > Norm-DB also Excel o. mit Runtime-Installation bzw. DLL eine > SQL-Version. Ist aber vorgeschrieben, also nogo. > Weshalb mein Link da richtig war. Denn dann kann ich feststellen welche > Version von Access auf den Rechner ist, falls ich mich für > MDB(Access-Format) entscheide. Die Entscheidungsfreiheit besteht aber nicht. Abgesehen davon gibt es mehrere Wege wie ein entsprechender Provider auf das jeweilige System gekommen sein könnte. > Davon abgesehen, wenn man ein Start-Modul nutzt kann man eine Globale > Variable festlegen. Deren Status schreibt man in eine Ini-Datei oder > Registry. Im Start-Prg. liest man die aus, und übergibt sie an das > Haupt-Prg. . Da schreibt man eine if-then Anweisung nach den Motto. > > If bit_status = 32 bit then den_provider else den_ anderen Ja, gemurkster Coder der mit dem eigentlichen Problem so gar nichts zu tun hat und nicht im geringsten zur Lösung beiträgt, aber was solls ich weiß ja von wem es kommt. Blöd nur das der 32 Bit Provider den 64 Bit Provider ausschließt und umgekehrt. Die Anwendung muss zwangsweise in 64 Bit sein, also auch hier kein vernünftiges weiterkommen wenn der Provider als 32 Bit installiert ist, weil Office oder irgendetwas Anderes (Datenbank Anwendung) den schon in 32 Bit installiert hat. > Wenn das prg sauber beendet wurde, dann schreibt man den Bit_status > wieder in die Reg bzw. ini. Nicht relevant. > Somit stellt sich das Programm selbstständig richtig ein. > > Ähnliches machen übrigens viele Programme bei Sprachen wechsel. Auch hier wieder keine Relevanz.
Guest schrieb: > Hast du Libraries wie EPPlus in Betracht gezogen? Damit geht es viel > sauberer. Ja, nur war mir EPPlus dafür zu aufgebläht, hab jetzt ExcelDataReader (https://github.com/ExcelDataReader/ExcelDataReader, gibt es au als NuGet-Paket) ausprobiert und es sieht soweit gut aus. Ein kurzer Überflug des Quelltextes zeigt, dass die es genau so machen wie ich es selber vorhatte, also entzippen und xml selber auswerten, darum auch keine Provider Abhängigkeiten. Traurig das Microsoft durch diese unsägliche 32/64 Bit Geschichte die OLEDB Provider praktisch untauglich macht, aber ist eben so.
Eine Frage rein aus Interesse (ich bin nicht firm mit Windows/C#): Was hat es mit dieser ganzen Provider/OLEDB-Geschichte auf sich? Unter Python gibt es diverse Libraries, da reicht ein Zweizeiler und ich hab ein Excel/Open-Document-Sheet in einem zweidimensionalen Array (oder einer komplexeren Datenstruktur). Gibts bei C# sowas nicht?
:
Bearbeitet durch User
Le X. schrieb: > Was hat es mit dieser ganzen Provider/OLEDB-Geschichte auf sich? Wieso man ein Provider für Excel braucht ist mir auch nicht klar. Aber ich weiß nicht alles. Wie gesagt ich bearbeite Excel via INTEROP-Befehlen. Das sind eigentlich auch nur wenige Befehle. Sieht so aus. Imports Microsoft.Office.Interop.Excel.XlApplicationInternational Public excel As New Microsoft.Office.Interop.Excel.Application excel.Workbooks.Open(excel_pfad) wert = excel.Rows(zeile).cells(spalte).value Gekürzter Code. Nur die reinen Excel-Befehle
Nachtrag: Excel-Dateien in eine Datenbank zu befördern und dann nach Norm auszugeben ist aktuell mein "Täglich Brot".
Falls die Dateien aus einen Excel >2007 kommen geht auch folgender Trick. Mal kopiert die Excel-datei. Dann Entpackt mal sie mit ein Zip-code. Und liest danach die XML-Datei aus. Interop gilt ja als veraltert. ;)
Le X. schrieb: > Eine Frage rein aus Interesse (ich bin nicht firm mit Windows/C#): > Was hat es mit dieser ganzen Provider/OLEDB-Geschichte auf sich? Im Prinzip kannst du das ganze am performantesten und mit maximaler Kompatibilität über die von Microsoft zur Verfügung gestellten OLEDB Provider machen. Dabei kannst du praktisch mit SQL direkt auf den Sheets arbeiten. > Unter Python gibt es diverse Libraries, da reicht ein Zweizeiler und ich > hab ein Excel/Open-Document-Sheet in einem zweidimensionalen Array (oder > einer komplexeren Datenstruktur). > Gibts bei C# sowas nicht? Doch sowas gibts auch, ich benutze mit ExcelDataReader ja jetzt letztlich so etwas, nur haben solche Libs unter C#, wie auch bei Python, teilweise eine zweifelhafte Qualität gegenüber der vom Excel-Hersteller angebotenen und empfohlenen Variante (ACE OLEDB Provider). Schlaumaier schrieb: > Le X. schrieb: >> Was hat es mit dieser ganzen Provider/OLEDB-Geschichte auf sich? > > Wieso man ein Provider für Excel braucht ist mir auch nicht klar. Wie so vieles andere auch. > Aber ich weiß nicht alles. Wie gesagt ich bearbeite Excel via > INTEROP-Befehlen. Das sind eigentlich auch nur wenige Befehle. Ohne Excel kein Interop, aber du bist ja Resistent bzw. Immun gegen diese Information. > Sieht so aus. > > Imports Microsoft.Office.Interop.Excel.XlApplicationInternational > > Public excel As New Microsoft.Office.Interop.Excel.Application > > excel.Workbooks.Open(excel_pfad) > > wert = excel.Rows(zeile).cells(spalte).value > > > Gekürzter Code. Nur die reinen Excel-Befehle Toll und ohne Excel? Schlaumaier schrieb: > Nachtrag: > > Excel-Dateien in eine Datenbank zu befördern und dann nach Norm > auszugeben ist aktuell mein "Täglich Brot". Das macht deine Vorgehensweise auch nicht besser. Schlaumaier schrieb: > Falls die Dateien aus einen Excel >2007 kommen geht auch folgender > Trick. Natürlich kommen die aus Excel >2007, sind ja xlsx und keine xls Dateien, aber mit dem Lesen hast du es ja eh nicht unbedingt. > Mal kopiert die Excel-datei. Dann Entpackt mal sie mit ein Zip-code. Und > liest danach die XML-Datei aus. Oder man macht genau das im Speicher, oder noch besser man lässt das eine Lib machen, wenn ich doch nur wüsste welche Lib sowas machen kann?!? Achja, hatte ich ja gerade erst oben beschrieben, die ExcelDataReader Lib macht genau das. > Interop gilt ja als veraltert. ;) Ohne Excel sogar als unbrauchbar...
Tim T. schrieb: > Achja, hatte ich ja gerade erst oben beschrieben, die > ExcelDataReader Lib macht genau das. Klasse. Für eine einfache Aufgabe eine Lib. Das macht man mit den eingebauten xml-Reader viel einfacher. Aber du kannst es ja besser. Ich nutze fremde Libs nur wenn es unbedingt sein muss. Dann laufen meine Programme auf 32 Bit + 64 Bit Systemen nämlich Stressfrei. ;) Und der Installer erledigt auch das Provider-Problem. Der guckt nämlich nach und installiert notfalls die 64 Bit Version anstelle der 32 Bit-Version.
Schlaumaier schrieb: > Tim T. schrieb: >> Achja, hatte ich ja gerade erst oben beschrieben, die >> ExcelDataReader Lib macht genau das. > > Klasse. Für eine einfache Aufgabe eine Lib. Das macht man mit den > eingebauten xml-Reader viel einfacher. > > Aber du kannst es ja besser. Und wie entzippst du die xlsx? > Ich nutze fremde Libs nur wenn es unbedingt sein muss. Dann laufen meine > Programme auf 32 Bit + 64 Bit Systemen nämlich Stressfrei. ;) Nein, DU brauchst dafür ein ganzes Excel. Und bis auf die Problematik 32/64 Bit war die Provider Variante bislang auch stressfrei. > Und der Installer erledigt auch das Provider-Problem. Der guckt nämlich > nach und installiert notfalls die 64 Bit Version anstelle der 32 > Bit-Version. DU ******* ******* wenn du ein 32 Bit Office installiert hast, oder auch nur die 32 Bit Access DB Runtime, kannst du die 64 Bit Variante NICHT mehr installieren...
:
Bearbeitet durch User
Tim T. schrieb: > Und wie entzippst du die xlsx? https://learn.microsoft.com/de-de/dotnet/standard/io/how-to-compress-and-extract-files SO. Tim T. schrieb: > DU ******* ******* wenn du ein 32 Bit Office installiert hast, oder auch > nur die 32 Bit Access DB Runtime, kannst du die 64 Bit Variante NICHT > mehr installieren... Richtig. Deshalb schaut der Installer nach und schreibt in das Desktop-Icon beim Aufruf einen Parameter (falls du keine Registry magst). Den lese ist aus, und rufe den passenden Provider aus. 2. Lösungen für das selbe Problem. Ich bevorzuge die Auspack-Methode wenn ich keine Excel-Version zu verfügung habe.
Schlaumaier schrieb: > Tim T. schrieb: >> Und wie entzippst du die xlsx? > > https://learn.microsoft.com/de-de/dotnet/standard/io/how-to-compress-and-extract-files > > SO. Genau, du landest wieder im Dateisystem, mit allen Problemen. Mit einer extra Lib spielt sich alles im Ram ab. > Tim T. schrieb: >> DU ******* ******* wenn du ein 32 Bit Office installiert hast, oder auch >> nur die 32 Bit Access DB Runtime, kannst du die 64 Bit Variante NICHT >> mehr installieren... > > Richtig. > > Deshalb schaut der Installer nach und schreibt in das Desktop-Icon beim > Aufruf einen Parameter (falls du keine Registry magst). > > Den lese ist aus, und rufe den passenden Provider aus. Es gibt nur immer jeweils einen ACE OLEDB xx.0, da hast du einfach keine Wahl ob du den in 32 oder in 64 Bit hast. Und wie schon zig mal geschrieben ist meine Anwendung zwangsläufig eine 64 Bit App, wenn dann der Provider als 32 Bit auf dem System installiert ist, warum auch immer, ist an der Stelle einfach Ende. Da helfen auch keine 1000 Parameter am Arsch der Welt nicht weiter. Bist du wirklich dermaßen doof, das du es einfach nicht raffst? DU KANNST DEN PROVIDER NUR ALS 32 ODER 64 BIT AUF DEM SYSTEM HABEN, NICHT BEIDES. UND ICH BRÄUCHTE DEN ZWANGSLÄUFIG ALS 64 BIT. WO HILFT DA BITTE DEIN SCHEIẞ PARAMETER? > 2. Lösungen für das selbe Problem. Keine Lösung für irgendein Problem. > Ich bevorzuge die Auspack-Methode wenn ich keine Excel-Version zu > verfügung habe. Du besitzt nicht im Ansatz die Fähigkeiten aus den entpackten XML Dateien die benötigen Daten zu extrahieren, da du dabei mehrere Dateien kombinieren musst um an alle Informationen zu kommen, aber schwätz nur weiter. Ich jedenfalls hab keinen Bock mehr mir dein Gebrabbel weiter durchzulesen. Von daher ist hier für mich EOD.
LINQ gibts auch noch. https://social.msdn.microsoft.com/Forums/en-US/08dca07b-2966-466d-8d58-086a9c21ddf4/using-linq-to-read-excel-sheet?forum=aspdatasourcecontrols
Hallo Tim, wir machen das unter C# mit dieser Lib https://www.thecodebuzz.com/read-and-write-excel-file-in-net-core-using-npoi/ ruß Frank
Tim T. schrieb: > Es gibt nur immer jeweils einen ACE OLEDB xx.0, da hast du einfach keine > Wahl ob du den in 32 oder in 64 Bit hast. Das stimmt so nicht ganz. Was stimmt, ist vielmehr dies: Der Installer (MDACsowieso) läßt es nicht zu, die 32Bit-Version zu installieren, wenn bereits die 64Bit-Version und/oder ein 64Bit-MS-Office installiert ist. Und umgekehrt gilt dieselbe Restriktion. In erster Instanz ist es also eine durch den Installer durchgesetzte Restriktion. Nun ist es aber so, dass das System grundsätzlich durchaus in der Lage ist, mit zwei "verschieden-bittigen" Versionen ein und desselben COM-Objektes umzugehen. Die werden einfach an verschiedenen Orten im Filesystem und der Registry installiert. Die Frage wäre also: Warum verhindert der Installer das für die OLEDB-Treiber? Oder andersrum: was passiert, wenn man ihm ein diesbezüglich "cleanes" System vorgaukelt und somit dazu bringt, die Installation durchzuführen, obwohl es die "entgegengesetzte" bereits gibt? Das muss man halt einfach mal ausprobieren und somit herausfinden, ob die Restriktion auf einen tatsächlichen technischen Grund hat oder nur eine rein marketingtechnische Intention verfolgt.
c-hater schrieb: > > Die Frage wäre also: Warum verhindert der Installer das für die > OLEDB-Treiber? Oder andersrum: was passiert, wenn man ihm ein > diesbezüglich "cleanes" System vorgaukelt und somit dazu bringt, die > Installation durchzuführen, obwohl es die "entgegengesetzte" bereits > gibt? > > Das muss man halt einfach mal ausprobieren und somit herausfinden, ob > die Restriktion auf einen tatsächlichen technischen Grund hat oder nur > eine rein marketingtechnische Intention verfolgt. Weil dann z.B. ein 32-Bit Office was den 32-Bit OLEDB mitgebracht hat dann den 64-Bit OLEDB benutzt, mit dem Ergebnis das es crasht. Da ich aber nicht die Wahl habe wohin welcher OLEDB auf den Zielsystemen installiert wird, ist das alles eh eine rein akademische Diskussion.
Tim T. schrieb: > Weil dann z.B. ein 32-Bit Office was den 32-Bit OLEDB mitgebracht hat > dann den 64-Bit OLEDB benutzt, mit dem Ergebnis das es crasht. Das sollte aber nicht so sein. Genau, um das zu verhindern, gibt's ja die SysWOW64-"Virtualisierung". Und dieser Mechanismus funktioniert durchaus bei Zehntausenden von 32Bit-Anwendungen. Und ausgerechnet bei einem Produkt aus dem eigenen Haus versagt er? Das wäre doch eine sehr seltsamer Zufall...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.