Внешняя таблица IIS и OLE DB не в ожидаемом формате

Question

У меня возникают очень странные проблемы с подключением OLE DB к книгам Excel.

В нашей системе есть большой шаблон с поддержкой макросов Excel (у нас есть Excel 2010 и Excel 2016). Иногда пользователь добавляет изображения, диаграммы, вкладки и т. Д., Которые выдают ошибку. Внешняя таблица не соответствует ожидаемому формату при попытке прочитать скрытую вкладку в книге, к которой у пользователей нет доступа.

Обычно у нас есть пользователь, загружающий новый шаблон и переделывающий работу без добавления картинок.

В последнее время было много случаев такого поведения, и я пытался исследовать на своем компьютере разработки. Я обнаружил, что не могу открыть соединение с "поврежденным" файлом через веб-сайт во время процесса загрузки файла, когда файл считывается в поток байтов, а временный файл.xlsm создается и открывается с использованием OleDbConnection, а данные считываются из скрытая вкладка.

Ничто из того, что я сделал с файлом, не открывало бы его для открытия через код, размещенный в IIS. Это включает в себя следующее:

• Удалить все картинки
• Удалить все вкладки, кроме скрытой вкладки
• Показать вкладку, с которой мы читаем
• сохранить книгу как xlsx для удаления макросов
• сохранить рабочую книгу как книгу 2003 - 2007, а затем сохранить обратно в xlsx или xlsm

Сайт работает под.NET Framework 4.0 и работает под IIS.

Для моего исследования я написал следующий код и разместил его на том же компьютере разработчика на странице тестового веб-приложения, размещенного в IIS Express в.NET Framework 4.0, и он успешно открыл и считал данные из исходного "поврежденного" файла.

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.OleDb;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

public partial class ReadExcelTabToDataSet : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        string szSheetName = @"C:\Temp\Test.xlsm";
        string szConnection = "Provider=Microsoft.ACE.OLEDB.12.0;Extended Properties=\"Excel 12.0;HDR=YES\";Data Source=" + szSheetName;

        string szQuery = "Select 'Configuration$' as Sheet, * From [Configuration$B1:S2]";
        string szExcelTableName = "ValidateFlag";
        DataSet ds;

        using (OleDbConnection conn = new OleDbConnection(szConnection))
        {
            using (OleDbDataAdapter da = new OleDbDataAdapter(szQuery, conn))
            {
                conn.Open();
                ds = new DataSet();
                da.Fill(ds, szExcelTableName);
            }
        }
    }
}

Это поднимает много предупреждающих звонков и ставит меня в тупик. Этот тест, похоже, исключает все, кроме того, как OleDb работает, когда размещается в IIS. Когда эта страница копируется на наш сайт, происходит сбой в conn.Open().

Кто-нибудь понимает, почему это происходит и как это исправить? Я не хочу наказывать наших пользователей за странные проблемы Microsoft, подобные этой.

Спасибо,

РЕДАКТИРОВАТЬ 1

Если файл помечен как "только для чтения" и находится в каталоге с полным доступом, тогда файл можно открыть и данные могут быть успешно прочитаны.

Это все еще представляет проблему, так как мы открываем файл, проверяем информацию и, наконец, вносим изменения на вкладке.

Answer 1

Я начал исследовать использование ClosedXml (решение.NET, основанное на OpenXML), чтобы обойти многие проблемы OleDb, с которыми я сталкиваюсь. При попытке открыть "поврежденные" книги с помощью ClosedXml я получил сообщение об ошибке, которое мне удалось скопировать с помощью Microsoft Open XML SDK.

Причиной проблемы является кнопка формы, которая выполняет код VBA для копирования данных в шаблоне с одной вкладки на другую. Текст в кнопке формы содержал возврат каретки (т. Е. Br). Когда размер шаблона становится большим, и пользователь сохраняет свою работу, Excel повреждает HTML, не закрывая br. В то время как команда ACE OleDB не предоставляет никаких указаний, Open XML SDK предоставляет следующее сообщение:

Не удается открыть файл: Part /xl/drawings/vmlDrawing4.vml: начальный тег 'br' в строке 19, позиция 29 не соответствует конечному тегу 'font'. Строка 20, позиция 9.

Если расширение шаблона переименовано из.xlsm в.zip, фактический файл может быть проверен и причина может быть устранена. В этом случае мне пришлось убрать разрыв между словами на кнопке.

Меня беспокоит, что Excel становится нестабильным при увеличении размера файла и не сохраняет правильные книги в этот момент, но я могу обойти этот случай.

Answer 2

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

Лучше всего было бы проверить вашу программу, протестировать ее с новым файлом и найти ошибку таким образом.

Удачи!

Answer 3

Я получал такое же сообщение об ошибке при использовании подключения ADO из одной книги Excel (A) к другой книге Excel (B). Рабочая книга A открыта пользователем, а рабочая книга B закрыта, но подключена к ADO в режиме чтения / записи.

Ошибка "Внешняя таблица не в ожидаемом формате" возникает при обновлении и сохранении книги B в ADO, но при заполнении диска.

Ошибки заполнения диска не должны быть распространенными, и они довольно просто устраняются, если рабочая книга открыта пользователем, потому что пользователь предупрежден и может сохранить рабочую книгу в другой области. Однако при открытии через ADO-соединение предупреждение отсутствует, и поэтому рабочая книга (в данном случае B) не сохраняется правильно и становится поврежденной - по крайней мере, это то, что я пришел к выводу.

Когда впоследствии рабочая книга B открывается пользователем, появляется предупреждение о том, что рабочая книга повреждена. После попытки восстановления книга кажется пустой. Однако закрытие книги B и последующий запуск SQL-запроса к ней (соединение ADO в режиме только для чтения) иногда возвращает данные (в зависимости от степени повреждения), но данные неполные.

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