OleDB, не поддерживаемый в режиме на 64 бита?

Основная проблема заключается в том, что СУБД Jet представляет собой 32-битную библиотеку, которая загружается в вызывающий процесс, поэтому вы никогда не сможете использовать Jet непосредственно из своего приложения в 64-битный режим. Как упоминал Тим, вы можете написать свой собственный синтаксический анализатор csv, но, поскольку это приложение с усадкой, вам нужно что-то, что будет обрабатывать более широкий диапазон форматов. К счастью, есть несколько способов говорить о 32-битных приложениях, так что вы все равно можете использовать Jet с хитростью.

Я бы написал небольшой исполняемый файл, который был помечен для работы только в 32-битном режиме. Этот исполняемый файл принимает в качестве аргумента командной строки имя файла для чтения и имя временного файла для записи. Я бы использовал Jet для загрузки csv / xls, затем поместил данные в массив массивов и использовал сериализатор xml для записи данных во временный файл.

Затем, когда мне нужно загрузить / преобразовать csv / xls файл, Я бы сделал следующее:

object[][] ConvertFile(string csvOrXlsFile)
{
    var output = System.IO.Path.GetTempFileName();
    try
    {
        var startinfo = new System.Diagnostics.ProcessStartInfo("convert.exe",
            string.Format("\"{0}\" \"{1}\"", csvOrXlsFile, output));

        System.Diagnostics.Process proc = new System.Diagnostics.Process();
        proc.StartInfo = startinfo;

        proc.Start();
        proc.WaitForExit();

        var serializer = new System.Xml.Serialization.XmlSerializer(typeof(object[][]));
        using (var reader = System.IO.File.OpenText(output))
            return (object[][])serializer.Deserialize(reader);
    }
    finally
    {
        if (System.IO.File.Exists(output))
            System.IO.File.Delete(output);
    }
}

Вы можете попробовать библиотеку FileHelpers для синтаксического анализа плоских файлов. Работает на удивление хорошо.

Actually I think Linq is your best solution for this.

Something like....

IEnumerable<MyObj> ObjList = GetObjList(yourCSVFileNAme);

var qry = from o in ObjList
          where o.MyField == Something
          select o;

and your GetObjList method looks something like

Public IEnumerable<MyObj> GetObjList(string filename)
{
  // Obvioulsly you would have some actual validation and error handling
  foreach(string line in File.ReadAllLines(filename))
  {
    string[] fields = line.Split(new char[]{','});
    MyObj obj = new MyObj();
    obj.Field = fields[0];
    obj.AnotherField = int32.Parse(fields[1]);
    yield return obj;
  }
}

Используйте свойство «Хранилище» с именем столбца:

[Column( Name="TBL_REGISTRATION_PK", Storage="TBL_REGISTRATION_PK", IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert )]
        public Guid RegistrationID { get { return _RegistrationID; } set { _RegistrationID = value; } }

Поскольку имя хранилища столбца - TBL_REGISTRATION_PK.

Вы не указали, является ли ваше приложение WinForms или ASP.NET, но SpreadsheetGear работает с ними. Вы можете увидеть живые образцы ASP.NET (C # и VB) здесь , узнать о примерах WinForms здесь и загрузить бесплатную пробную версию здесь , если вы хотите попробовать

Отказ от ответственности: я владею SpreadsheetGear LLC

Вы можете использовать Microsoft Access Database Engine Engine 2010 Redistributable Для чтения и записи CSV, XLS Access и т. Д. Существует 32 и 64-битная версия каждого драйвера.

Это скорее информационный пост для всех, кто может столкнуться с этой проблемой (и для меня самого на случай, если у меня возникнет такая же проблема в будущем и я не смогу вспомнить решение :-)). Это довольно непонятная проблема, но она заставила меня провести несколько часов в напряжении, так что, возможно, это поможет кому-то еще... Извините, если это повторяется (не смог найти) или устарело (у некоторых нет возможности пользоваться последним и самым лучшим).

Если вы пытаетесь использовать Jet 4.0 для доступа к документам MS Excel (или другим файлам данных) на сервере на базе x64, вы обнаружите, что эта комбинация не поддерживается.

Единственным решением является разрешение IIS запускать 32-битные приложения на Windows 64 и установка поддерживаемого db-провайдера.

Вам потребуется установить драйвер, 64-Bit OLEDB Provider for ODBC (MSDASQL), который действует как мост: "Microsoft OLE DB Provider for ODBC (MSDASQL) - это технология, которая позволяет приложениям, построенным на OLEDB и ADO (который использует OLEDB внутри), получать доступ к источникам данных через драйвер ODBC. MSDASQL - это провайдер OLEDB, который подключается к ODBC, а не к базе данных. MSDASQL поставляется с операционной системой Windows, а Windows Server 2008 и Windows Vista SP1 являются первыми выпусками Windows, включающими 64-битную версию этой технологии." Скачать здесь : http://www.microsoft.com/downloads/details.aspx?FamilyID=000364db-5e8b-44a8-b9be-ca44d18b059b&displaylang=en

Все это прекрасно работает, но я столкнулся с двумя вещами, которые заставили меня почесать голову (и напрячься): 1) Вам нужно разрешить 32-битный ASP.Net в IIS Web Service Extensions - Читайте ""http://www.textcontrol.com/blog/permalink/2006082101""" для инструкций по включению 32-битных приложений и настройке IIS Web Service Extensions. 2) Если вы используете какие-либо ключи реестра под IIS x64, в реестре будет добавлен новый узел - Wow6432Node, в который вам нужно будет переместить/скопировать все соответствующие ключи, которые использовались под x64. Например, у нас был ключ данных, хранящийся в HCLM\Software\CustomKey, который перестал быть доступным после включения 32-битной версии. Мы пересоздали ключ в Wow6432Node и все было в порядке.