Вопрос из зала: и не забыть commit?

Ответ: Нет. Не надо делать commit. У вас autocommitпо умолчанию на Connection!И сразу так у вас все изменится.

P.S. Первый параметр в createStatementотвечает за то, можете ли вы ходить по записям вверх и вниз? Ну понятное дело, что при параметре FORWARD_ONLY вы не можете. Но вы можете выбрать вариант «ХОЧУ!», т.е. дошли до чего-то и потом снова с начала пошли. Допустим вы считываете сотрудников пятого отдела, прошли по ним, вам это понравилось, вы хотите повторить это, вернулись на первую запись и пошли вниз. А там возникает два сценария. Представьте себе, что вы сейчас прочитали данные из БД, прошли по записи, вернулись на первую и снова по ним пошли. А вдруг изменилось состояние сотрудников пятого отдела. Вы хотите видеть изменения или нет? Если хотите, то вы выбираете вариант SENSITIVE. Т.е. он пойдет второй раз по данным, а данные на самом деле будут реально подтягивать из СУБД. И тогда вы просто можете говорить «first() и снова пошли и видите изменения» и снова по тоже кругу, и снова по тому же кругу. Вот такой курсор скушает много ресурсов. Но вот тот курсор, который по умолчанию READ_ONLY-FORWARD_ONLY, он никак не называется. А все остальные курсоры называются серверными курсорами, потому что они имеют все равно какую-то еще связь с сервером и если обновить нужно, то в данный сервер ведет обновление; если хотим видеть изменение, значит должна быть связь с сервером. Поэтому у них у всех остальных есть такое общее название «серверный курсор». Microsoftот этой технологии отказался сразу. У них есть только технология для доступа к данным «READ_ONLY-FORWARD_ONLY». Ну это вопрос реализации. Ну там сказали, что нам не нужны эти проблемы. Хочешь менять, сделай нормальную команду UPDATE. А здесь можно с SELECTменять серверным курсором. Поэтому я обычно спрашиваю на этом месте: «будем мы с помощью SELECT менять?». Да.

Когда у нас дело дойдет до внесения изменений, я попрошу, чтобы в этой таблице появились ваши «Имя» и «Фамилия», а я за одно отмечу тех, кто здесь присутствует.

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

Как обрабатывать исключения? Вроде бы все на самом деле знакомо, есть try-catchи т.д., но здесь одно маленькое «но». Оно выделено на этом слайде вначале и вконце.

Дело в том, что как поступает любой компилятор? Вы делаете одну синтаксическую ошибку, а он выдает 30 ошибок. Почему? Ну с какого-то момента ему перестало быть все понятно. И он комментирует это. Точно также если вы допустите ошибку в тексте на SQL, то вам могут выставить несколько сообщений. А Exception-то он один! Поэтому разработчики сделали, что SQLExceptionв нем есть ссылка на следующий SQLExceptionи можно их по цепочке все разобрать. Вот для этого вы пишете цикл, а в конце getNextException(). Всё. Тем самым разбираете и смотрите. Ну а что там в этом объекте исключений? Естественно понятно, что кроме стандартных величин, здесь такие поля как getSQLState(), getDriverName(), getErrorCode() и т.д. Т.е. что-то будет естественно из того сообщения об ошибке, который мы привыкли видеть в SQL, что-то будет прямо здесь непосредственно в вашем объекте Exception. Так что, кто работал с SQL, то узнает эту всю информацию.

А вот ваш вопрос (следующий слайд): Как узнать названия столбцов? Да ради Бога! ResultSetMetaData.

Посмотрите основные вызовы, которые могут здесь пригодиться: · getColumnCount() · getColumnName() · getColumnTypeName() Т.к. у нас сегодня может быть switchпо строке, то вы можете написать основные названия типов и сделать внутри цикла, который читает по одной записи из ResultSet,сделать вариант переключения в зависимости от имени типа. Вполне будет рабочий сценарий.

Ну и вот добрались мы до изменений.

Понятно, что менять мы будем, конечно, используя стандартный подход. У нас есть для этого специальные команды в ЯП SQL. Но вот такая нестандартная ситуация «обновляемый курсор». Будьте внимательны, у нас программа, которая читает данные – есть. Именно в этой программе, вы должны будете сделать изменения в БД. Поэтому, первое, что вам придется сделать:

1. не забыть поменять курсор на обновляемый.

2. вам нужно будет установить, чтобы текущая запись была именно та, которую вы собираетесь изменить. Ну повезло только тому, у кого номер «1». Поэтому всем остальным придется дойти до нужной записи. Кстати, там нет варианта «перейди на запись с номером 15». И как вы попадете на нужную запись – вариантов много. Подумайте. Кстати, когда вы делаете сам запрос, то у объекта ResultSet есть поле до первой записи и поле после последней; т.е. курсор установлен до первой записи.И мы не начинаем читать, а говорим «next». И курсор попадает на первую запись. Есть такой стиль, который применяется в БД «BEFORE», «AFTER». Так что какой-то вариант переключения на нужную запись должен быть обязательно, но перейди на 15 нет.

Дальше, что вы делаете. Пожалуйста, вот он, updateString(). У вас должно быть указана запись, много столбцов. Поэтому вы знаете, какой в каждом столбце тип данных. Ну и если мы меняем имя и фамилию, то строки, понятно – значит вам подойдет updateString(). Вы пишете имя или №столбца, но у нас есть с вами печать, мы знаем с вами нумерацию. Поэтому останется только во втором параметре написать имя или фамилию. Где вы сейчас сделали изменение при вызове updateString()? Ответ: В курсоре. Курсор в себе эту информацию хранит. И если вы считаете, что все эти изменения, которые вы сделали в текущей строчке (в курсоре) не надо, то это неправильно. Вот есть cancelRowUpdates().

А вот updateRow(), и вот это приведет к тому, что данные попадут в БД. update() –это изменение, а мы можем с помощью обновляемого курсора и добавить строчку. Посмотрите, вот он код (слайд 31).

Выглядит примерно также, как и в жизни, когда вы пользователю говорите: «введи новую информацию». Вы ему пустую формочку на экране выводите, а здесь есть специальная команда, которая как бы позволяет заполнить пустую строчку в этом объекте ResultSet – метод moveToInsertRow(). Маркер текущей позиции перешел на специальную строчку для добавления, но ваши столбцы – это ваши столбцы. Вы аккуратненько туда (в нужные мне столбцы) ставите значения используя update’ы, а потом insertRow(). И она добавляется в БД. Вариант с deleteя даже писать не стал. Встали на нужную вам запись, выбрали deleteRow() и ее не будет в БД. Вы видите, что никаких commit() здесь нет. Почему? А зачем они нужны? У нас по умолчанию autocommit(). Каждое действие – это атомарное действие, которое сразу принимается в БД. Итак, я возвращаюсь там, где был update() и мы сейчас с вами должны вот эту таблицу привести в порядок. Потому что имена я пока не узнаю.

P.S.: Когда вы работаете с БД и вы не меняли настройки в объекте Connection, то у вас autocommit. Это значит, что каждое действие сразу сохраняется в БД. Метод updateString() не работает с БД, а updateRow() работает.Т.е. если выключить autocommit, то updateRow() изменение сделает в БД, но т.к. вы потом не вызовите commit() и закроете соединение, то БД сделает откат.

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