Блог

Я разместил приведенный ниже код на форуме разработчиков Sun, так как думал, что это ошибка (истинная ошибка была до того, как этот код был даже нажат). В одном из ответов, которые я получил, говорилось, что это не сработает и выбросить его. Но это действительно работает. Возможно, это не самый лучший код (я новичок в Java), но есть ли в нем что-то изначально «неправильное»?

=============

код:

 private static void ImportFromCsvToAccessTable(String mdbFilePath, String accessTableName 
, String csvDirPath , String csvFileName ) throws ClassNotFoundException, SQLException {

    Connection msConn = getDestinationConnection(mdbFilePath);
    try{

        String strSQL = "SELECT * INTO "   accessTableName   " FROM [Text;HDR=YES;DATABASE="   csvDirPath   ";].["   csvFileName   "]";
        PreparedStatement selectPrepSt = msConn.prepareStatement(strSQL );
        boolean result = selectPrepSt.execute();        
        System.out.println( "result = "   result );

    } catch(Exception e) {
        System.out.println(e);
    } finally {
        msConn.close();
    }
}
  

Буквальный ответ отрицательный — в коде никогда не бывает ничего «изначально неправильного», вопрос в том, соответствует ли он требованиям, которые могут включать или не включать в себя удобство обслуживания, безопасность, надежность или скорость.

Код, который вы запускаете, на самом деле является JET-запросом исключительно в Access — Java-код ничего не делает, кроме указания Access выполнить запрос.

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

Две вероятные причины, по которым он может сломаться::

1. Риск внедрения SQL. В зависимости от того, откуда берутся csvDirPath и csvFileName (например, csvFileName может исходить из имени файла, загруженного пользователем?), И от того, насколько умен драйвер Access JDBC, вы можете быть открыты для того, чтобы кто-то взломал или удалил ваши данные, вставив точку с запятой (или несколько скобок для создания подзапроса)и некоторые дополнительные команды SQL в запросе.
2. Вы полагаетесь на то, что столбцы файла CSV совместимы со столбцами таблицы Access. Если у вас загружается непроверенный CSV, или если генератор CSV имеет особый способ обработки нулей, или если вы однажды получите необычный формат даты или числа, вы можете получить ошибку при вставке в таблицу Access.

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

Если это класс, который является частью веб-приложения, то «официальным» способом Java для этого было бы считывать записи из файла CSV (либо с помощью анализатора CSV, либо с помощью драйвера CSV / text JDBC), извлекать столбцы из набора записей, выполнять некоторую проверку илипроверка работоспособности на них, а затем используйте новое PreparedStatement для вставки их в базу данных Access. Гораздо больше проблем, но гораздо надежнее.

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

Одно предупреждение — запросы jdbc -> Access (которые соединяются с использованием odbc) не работают в 64-разрядных системах, поскольку не существует 64-разрядных драйверов базы данных Access (драйвер включен в 32-разрядные копии Windows и может быть доступен только 32-разрядным процессам. Вы можете запустить «odbcad32» или посмотреть на панель управления ODBC, чтобы убедиться, что драйвер присутствует)

Хотя я не вижу кода со строкой подключения в вашем фрагменте кода, я не знаю ни о каких некоммерческих драйверах Access JDBC для Java, только jdbc-> odbc bridging и полагаюсь на Windows, чтобы иметь драйвер Access (* .mdb). Microsoft больше не поддерживает этот драйвер и не планирует переносить его на 64-битную версию, поэтому с точки зрения инфраструктуры об этом стоит подумать.

@david.w.fenton.myopenid.com : «Можете ли вы привести цитату о планах MS никогда не внедрять 64-разрядные драйверы ODBC для Jet?»

Дэвид, я нашел сообщение об этом в отзыве Microsoft Connect.

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx ?FeedbackID=125117

«На данный момент команда Office не планирует выпускать 64-разрядную версию JET driver. Мы можем рассмотреть альтернативные варианты и сообщим вам, когда у нас будет конкретный план «.

Спасибо, команда SSIS. Опубликовано Microsoft 3.10.2007 в 9: 47 вечера

В этом потоке отзывов не было обновлений от Microsoft.

Вопрос к Джошуа Маккиннону:

Можете ли вы привести цитату о планах MS никогда не вводить 64-разрядные драйверы ODBC для Jet? Это звучит разумно, поэтому я нисколько в вас не сомневаюсь, я просто хотел бы знать, есть ли у вас источник для этого, на который вы можете указать.

Конечно, MS предоставляет доступ к Jet в 64-разрядных системах через OLEDB, не так ли? Это не помогает с JDBC, но, безусловно, предоставляет способ использования данных Jet (они должны что-то предоставлять, поскольку Jet 4 является частью ОС, поскольку он используется в качестве хранилища данных для Active Directory и используется таким образом с Windows 2000).