Нерегулярное System.Data.OleDb.OleDbException (0x80004005): проблема с недопустимым аргументом

В производственной системе мы ИНОГДА получаем сообщение об ошибке ниже при чтении excel в datatable (тот же код, тот же файл не будет работать сегодня, но будет работать в другой день).

System.Data.OleDb.OleDbException (0x80004005): неверный аргумент. System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling(OleDbHResult hr) в System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS dbParams, Object& executeResult) в System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult) в System.Data.OleDb .OleDbCommand.ExecuteCommand (поведение CommandBehavior, Object& executeResult) в System.Data.OleDb.OleDbCommand.ExecuteReaderInternal (поведение CommandBehavior, метод String) в System.Data.OleDb.OleDbCommand.ExecuteReader (поведение CommandBehavior) в

System.Data.OleDb.OleDbCommand.System.Data.IDbCommand.ExecuteReader (поведение CommandBehavior) в System.Data.Common.DbDataAdapter.FillInternal (набор данных DataSet, таблицы данных DataTable [], Int32 startRecord, Int32 maxRecords, String srcTable, команда IDbCommand, поведение CommandBehavior) в System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, команда IDbCommand, поведение CommandBehavior) в System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)

Но проблема в том, что на рабочем сервере сегодня работает хорошо, а завтра или послезавтра не будет работать, а потом снова начнет работать хорошо.

Ниже приведен код.

     string ConnectionString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + readFilePath + ";Extended Properties=\"Excel 12.0;\""; 
     ExcelConnection = new OleDbConnection(ConnectionString); 
     string ExcelQuery = "Select FORMAT(SAMPDATE,'dd/MM/yyyy') as SAMPDATE,FORMAT(LANDED_ON,'dd/MM/yyyy') as LANDED_ON,FORMAT(RECDATE,'dd/MM/yyyy') as RECDATE,* from [Sheet1$]";

     ExcelCommand = new OleDbCommand(ExcelQuery, ExcelConnection); 

     ExcelConnection.Open(); 

     ExcelAdapter = new OleDbDataAdapter(ExcelCommand); 

     ExcelAdapter.Fill(dtbExcelData); 

     ExcelConnection.Close();

Я также проверил правильность значения переменной readFilePath, например, значение D:\Cop\Web\ABC\PAL\FIleUploaded\ER01.xls.

Я не уверен, почему точно такой же код не позволяет загружать тот же документ Excel, но на следующий день тот же код и тот же файл работает без проблем. Кто-нибудь может мне помочь?


person Sagar Shirke    schedule 23.11.2017    source источник
comment
Это должны быть ваши данные (электронная таблица). Вы отлаживали те, которые работают, и те, которые не работают.   -  person Crowcoder    schedule 23.11.2017
comment
@Crowcoder.. Если это связано с данными, то как на следующий день будет загружен тот же файл Excel, поскольку он загружается без каких-либо проблем. Но спасибо, я еще раз проверю это и поделюсь выводами с вами. Спасибо   -  person Sagar Shirke    schedule 23.11.2017
comment
Точно такой же файл? Те же данные? Зачем вам импортировать одни и те же точные данные более одного раза?   -  person Crowcoder    schedule 23.11.2017
comment
Знаете ли вы, запускается ли процесс excel в фоновом режиме при использовании этого кода? потому что это может привести к сбою, потому что процесс excel не запускается   -  person Franck Ngako    schedule 23.11.2017
comment
@Crowcoder.. На самом деле, если файлы не работают сегодня, мы снова пытаемся загрузить их в ближайшие несколько дней. Вот тогда мы и узнали об этой аномалии.   -  person Sagar Shirke    schedule 23.11.2017
comment
@FranckNgako .. спасибо за ваш комментарий .. Нет, в фоновом режиме не запущен процесс Excel. На самом деле у нас нет MS Office на рабочем сервере, поэтому мы не используем параметр взаимодействия.   -  person Sagar Shirke    schedule 23.11.2017
comment
в порядке. Ну, я не уверен, и не спрашивайте меня, почему. но каждый раз, когда вы используете interops dll на серверах, вы можете создать каталог с именем Desktop в расположении `C:\Windows\SysWOW64\config\systemprofile` и сообщить мне через пару дней, если это решило вашу проблему.   -  person Franck Ngako    schedule 23.11.2017
comment
@FranckNgako ... Я не использую взаимодействие на сервере ... так что это может быть неприменимо для моего случая, но в этом случае эта проблема будет возникать каждый раз, а не когда-нибудь.   -  person Sagar Shirke    schedule 23.11.2017
comment
Я понимаю. Я все еще не думаю, что это имеет какое-либо отношение к коду, который вы показали. Возможно, попробуйте ClosedXml вместо этого прочитать данные листа и посмотреть, как это происходит.   -  person Crowcoder    schedule 23.11.2017
comment
@Crowcoder.. Вы правы, я тоже не думаю, что это связано с кодом. А скорее что-то на сервере, например, другие запущенные процессы, дату и время и т. д. Я пытаюсь найти те факторы на сервере, которые могут вызвать эту проблему.   -  person Sagar Shirke    schedule 23.11.2017
comment
хорошо, в тот день, когда это не удается, попробуйте очистить файл (удалить много строк) и попробовать, если он все еще падает. Но в вашем исключении stackTrace вы можете видеть, что ExecuteReader был вызван, что для меня означает, что данные плохо отформатированы. Как на следующий день все в порядке, я не могу сказать. Но поскольку вы манипулируете датами в своем запросе, это пахнет языковой проблемой.   -  person Franck Ngako    schedule 23.11.2017


Ответы (1)


Несколько предложений.

  1. Я подозреваю, что проблема в том, что существуют мошеннические экземпляры Excel/Access (не уверен, какой из них используется здесь), которые мешают процессу работать должным образом. Я бы запускал процесс один раз в день (или ночь), чтобы просто войти и закрыть любого затянувшегося клиента. У нас есть задания Excel, которые выполняются ежедневно, и неизменно всегда есть оставшиеся запущенные экземпляры, вызывающие проблемы, и вы даже не можете увидеть их выполнение, если не зайдете в диспетчер задач на вкладке «Процессы».

Если вы запустите что-то настолько простое, оно очистит все открытые экземпляры, даже те, которые вы не видите:

foreach (var process in Process.GetProcessesByName("Excel"))
{
    process.Kill();
}
  1. @Crowcoder дал отличное предложение по использованию ClosedXml. Это или множество других сторонних программ чтения могут читать файлы Excel без использования OLE и без каких-либо зависимостей, выходящих за рамки самой платформы .NET.

С вашей стороны потребуется больше работы, чтобы прочитать содержимое и превратить его в таблицу данных, но это также создает возможность пропустить всю таблицу данных, что может иметь смысл, в зависимости от того, что вы пытаетесь сделать.

  1. Ваши комментарии указывают на то, что проблема не в самом содержании электронной таблицы, но я не могу не быть несколько подозрительным... в конце концов, это электронная таблица. В электронной таблице не существует такой вещи, как строгая типизация данных. OLE может определить, что столбец относится к определенному типу данных, только для того, чтобы найти ячейку, в которой почти все даты содержат слово «НЕТ» в одной ячейке.

Здесь нужно попробовать две вещи: во-первых, используйте устройство чтения данных вместо таблицы данных. Это позволяет ничего не предполагать.

В этом примере я думаю, что столбец A является датой, но вместо того, чтобы что-либо предполагать, я отображаю его как строку и использую DateTime.TryParse для проверки.

ExcelCommand = new OleDbCommand(ExcelQuery, ExcelConnection);
OleDbDataReader reader = ExcelCommand.ExecuteReader();

DateTime orderDate;

while (reader.Read())
{
    string colA = reader.GetValue(0).ToString();
    if (DateTime.TryParse(colA, out orderDate))
    {
        // do something with orderDate here
    }
}

reader.Close();

Честно говоря, я не уверен, что это сработает, но, возможно, стоит попробовать, если вы не уверены на 1000%, что проблема не в содержании.

Понятно, что это намного больше работы, чем просто запихивание содержимого в таблицу данных, но, честно говоря, я все равно никогда не был поклонником таблиц данных.

  1. Мое последнее предложение - возможно, используйте Interop, чтобы экспортировать файл в формате CSV и загрузить его таким образом. Это не очень хорошее предложение, так как вы создаете зависимость Excel, которая может быть частью проблемы в первую очередь.
person Hambone    schedule 26.11.2017