Laden...

Fehler: 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert"

Erstellt von OXO vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.881 Views
O
OXO Themenstarter:in
86 Beiträge seit 2020
vor 3 Jahren
Fehler: 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert"

Hallo zusammen,

leider hakelt es bei mir und meiner Anwendung wohl am laufenden Band.

Ich möchte in meiner Anwendung die Google OR Tools verwenden, wofür ich wohl meine Anwendung auf x64 für den Compile umstellen muss.

Mit der Anwendung wollte ich aber auch Daten aus einer Excel-Tabelle per OleDbConnection auslesen. Das klappt aber mit einem Compile auf x64 wohl nicht mehr und beim Versuch Daten aus der Excel auszulesen kommt die Fehlermeldung:

Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert" beim Import einer Excel-Datei.

Ich habe Excel 2007 und auch eine Excel-Datei, die damit erstellt ist. Unter x86 bzw. 32-Bit klappt zwar das Einlesen der Excel-Tabelle ohne Probleme, aber die Google OR Tools wollen damit dann nicht mehr.

Wie bekomme ich denn diese Beiden Welten am besten verheiratet?

16.828 Beiträge seit 2008
vor 3 Jahren

Der Fehler war schon hunderte Male im Forum. Daher bitte das nächste Mal zuerst die Forensuche nutzen. Danke 😉

Wie bekomme ich denn diese Beiden Welten am besten verheiratet?

So gar nicht.

Damit Deine Anwendung mit Excel sprechen kann, müssen zwingend die Architekturen (x86 / x64) übereinstimmen.
Da Excel 2007 aber nur als x86 zur Verfügung steht, kannst Du entsprechendes nicht als x64 installieren.
Die Google Tools wollen x64; daher kannst Du beide Welten hier nicht verheiraten.

Du musst Dich also von einem der beiden trennen, zB. Excel durch OpenXML ersetzen.
Alternativ über einen dritten Prozess kommunizieren (zB Windows Service mit gRPC Schnittstelle).

O
OXO Themenstarter:in
86 Beiträge seit 2020
vor 3 Jahren

Der Fehler war schon hunderte Male im Forum. Daher bitte das nächste Mal zuerst die Forensuche nutzen. Danke 😉

Hallo Abt,

die hatte ich schon gelesen und gesehen, dass es am x86/x64 vermutlich auch hier liegt. Vielleicht einfach die Frage, ob es eine elegante Lösung gibt.

Ich habe es nun so gelöst, dass ich auch das *.xlsx über das OpenDocument SDK einlese


using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Spreadsheet;
using System.Data;
...

private DataTable ReadExcelSheetToDataTable(string pathExcelFile)
{
	DataTable dt = new DataTable();
	
	dt.Columns.Add("Column 1");
	dt.Columns.Add("Column 2");
	dt.Columns.Add("Column 3");
	dt.Columns.Add("Column 4");
	dt.Rows.Add();  // First of all add an Empty Row

	using (SpreadsheetDocument doc = SpreadsheetDocument.Open(pathExcelFile, false))
	{
		// Read the first Sheet
		Sheet sheet = doc.WorkbookPart.Workbook.Sheets.GetFirstChild<Sheet>();
		Worksheet worksheet = (doc.WorkbookPart.GetPartById(sheet.Id.Value) as WorksheetPart).Worksheet;
		IEnumerable<Row> rows = worksheet.GetFirstChild<SheetData>().Descendants<Row>();
		
		int counter = 0;
		foreach (Row row in rows)
		{
			counter = counter + 1;

			// Skip first 3 rows as header
			if (counter >= 3)
			{                        
				dt.Rows.Add();
				int i = 0;
				foreach (Cell cell in row.Descendants<Cell>())
				{
					dt.Rows[dt.Rows.Count - 1][i] = GetCellValue(doc, cell);
					i++;
				}
			}
		}

	}

	return dt;
}

private string GetCellValue(SpreadsheetDocument doc, Cell cell)
{
	string cellValueText = cell.CellValue.InnerText;
	Double value = Double.Parse(cellValueText, NumberStyles.AllowExponent | NumberStyles.AllowDecimalPoint, CultureInfo.InvariantCulture) / 100;

	if (cell.DataType != null && cell.DataType.Value == CellValues.SharedString)
	{
		return doc.WorkbookPart.SharedStringTablePart.SharedStringTable.ChildElements.GetItem(int.Parse(cellValueText)).InnerText;
	}
	return value.ToString();
}