Java-код для импорта CSV в Access - PullRequest
0 голосов
/ 27 августа 2008

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

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

КОД:

</p>

<code>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();
    }
}
</code>

Ответы [ 4 ]

5 голосов
/ 27 августа 2008

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

Код, который вы выполняете, на самом деле является 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. Гораздо больше проблем, но гораздо надежнее.

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

2 голосов
/ 28 августа 2008

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

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

1 голос
/ 19 сентября 2008

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

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

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

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

Спасибо, Команда служб SSIS. Написал Microsoft 3.10.2007 в 21:47

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

0 голосов
/ 16 сентября 2008

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...