 | | | | |
| Опыт прикладного программиста в деле перевода базы данных с MS Access на SQL-Server |
Полный текст материала
Другие публикации автора: Светлов Виктор
Цитата или краткий комментарий: | «... Хочу поделиться недавним опытом перевода базы данных из формата Access 2000 на платформу MS SQL Server 7.0. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 14 | 93.3% | | | | | Ничего особенно нового и интересного | | [2] | 1 | 6.7% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 15 | | | | Все понятно, материал читается легко | | [1] | 7 | 63.6% | | | | | Есть неясности в изложении | | [2] | 4 | 36.4% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 11 |
[MS SQL Server] [MS Access] [Импорт/экспорт данных]
Отслеживать это обсуждение 
Всего сообщений: 2515-03-2005 06:22Это обсуждение статьи, а не ответы на любые вопросы.
Для вопросов есть Кргулый стол.
Если здесь еще будут задаваться вопросы, отвлеченные от обсуждения самой статьи, то они будут удалены.
Именно по этой же причине, Виктор, я прошу Вас воздержаться от ответов на вопросы по SQL, а не по обсуждению Вашего материала. |
|
15-03-2005 03:27Спасибо за ответы. Попутно хочу задать ещё вопрос.
Как известно для передачи парметров сохраненному ф-ей SQLPrepare() SQL-запросу (SELECT * FROM MAIN WHERE Kod = ?) используется ф-я SQLBindParameter, а как получить результат в к-либо переменнию например такого запроса SELECT COUNT(Kod) FROM MAIN. В MSDN вычитал что делается это через procedure, а как реализовать не знаю.Сообщение не подписано |
|
12-03-2005 00:18сообщение от автора материала Доброе утро.
Вопрос: Eсли использовать запрос "SELECT * FROM Лицензия", т.е. выбрать все записи, каковы будут последствия, ведь размер БД превышает обьём памяти.
Ответ: О последствиях Вы уже знаете сами. Другое дело, что Вам не нужны все записи. Показывайте пустые окна списков (броузеры), в которых по фильтру юзер найдет нужные. Из броузера отрывайте редактор с одной записью.
Вопрос: И как лучше оптимизировать работу с БД по быстродействию, просто есть требование: время
отклика системы 3 сек., реально ли это вообще?
Ответ: см. предыдущий. Абсолютно реально, более того это у всех работает :)
Совет: перестаньте называть объекты БД русскими словами. Ничего хорошего из этого не выйдет. Если еще не столкнулись, то все у Вас впереди.
Удачи. |
|
07-03-2005 05:20У меня собственно такой вопрос:
есть БД в формате mdb, работаю я с ней через
ODBC API (дело довольно запаристое), размер БД
будет доходить до нескольких сотен тысяч записей, количество полей в каждой таблице в среднем 15,
если использовать запрос "SELECT * FROM Лицензия",
т.е. выбрать все записи, каковы будут последствия,
ведь размер БД превышает обьём памяти.
И как лучше оптимизировать работу с БД по быстродействию, просто есть требование: время
отклика системы 3 сек., реально ли это вообще? |
|
06-03-2005 02:51сообщение от автора материала Доброе утро.
Что-то я не понял суть Вашей претензии "сообщение не подписано". Если Вам хочется, напишите свою СУБД. А нам некогда это делать.
Ума не приложите: ADOXCatalog.Tables[TableName].Columns[0].Properties['Autoincrement'].Value := True;
А Вы документацию приложИте. Счетчик и автоинкремент разные "немного" разные вещи. Вы я смотрю не чайник. Хе-хе.
И почему Вы требуете, чтобы Jet соответствовал стандарту языка SQL? Это решать не нам с Вами. А если хочется, можно работать через драйвер ODBC. |
|
04-03-2005 07:58>>> Виктор Светлов
>>>Вопросов много, поэтому буду краток.
.. Гм .. Вообще-то в последних постах не было ни одного вопроса. Был небольшой отчет в контексте темы, о том как чайник, немного работавший с Access, попробовал перейти на MS SQL. И слегка сэкономить время других чайников, которых ожидает такая же перспектива.
>>> Делайте все без наворотов конкретных СУБД, пользуясь только тем, что дает стандарт SQL и проблем у Вас не будет
Ну это уж точно! Ничего не пишите кроме SELECT * FROM и будет всё ОК. А еще лучше ничего не писать, и никаких проблем!
Я, например, никак не могу обойтись без IIF/CASE/и т.п. (хотя бы для отсечения null), - это "наворот"?
К слову сказать, COALESCE и CASE входят в состав зарезервированных слов Microsoft Jet. Более того, Jet пытается такой запрос выполнить (т.е. элементарную затычку не удосужились сделать!). А ведь обработать это так же как и IIF – пара строчек кода. Я этого не понимаю..
И так далее..
>>>SQL-Server нет понятия "счетчик", и это не его вина - это стандарт.
Вот оно как..
Хорошо, что я этого не знал.
Но вот только ума не приложу, что создается таким кодом, одинаковым и для Access и для SQL Server:
ADOXCatalog.Tables[TableName].Columns[0].Properties['Autoincrement'].Value := True;
Или запросом, который одинаково успешно выполняется в обоих случаях:
CREATE TABLE ..
(Id INT IDENTITY PRIMARY KEY, ..
Или запросом SELET INTO из Access в SQL Server и наоборот, который таки создает таблицу с "счетчиком", если таковой имелся в исходной.
А вот у горбатой залипухи под громким названием "Data Transformation Service" такого "понятия" действительно нет.
В то время как процедура копирования таблицы из Access в SQL Server вместе с "счетчиками", ключами, индексами и всеми данными на Delpthi занимает один экран. Впрочем, желающие могут, конечно, править всё вручную, ведь "Поправить ручками недолго и несложно": всегда найдется энтузиаст, который с упорством насекомого будет править вручную несколько десятков, а то и сотен таблиц.
>>>Параметры разных типов.
>>>Если генерить текст запроса в виде единой строки, проблем не будет. Зато этим вы добьетесь независимости от формата СУБД.
Добьетесь, конечно. Если долго биться. Соберете коллекцию разных вариантов представления дат, например. И при этом будете надеяться, что данная версия провайдера или драйвера будет понимать её правильно.
Вообще, параметры, наверное придумали ленивые разгильдяи – программисты, которым не хотелось этого делать.
Вместо того, чтобы делать кучу проверок и преобразований, решили передавать всё через параметры соответствующего типа.
Не хотели проверять строку на наличие апострофов, например.
Ведь эти проклятые юзеры могут додуматься поискать в базе Д’артаньяна.
Или начнут искать на Круглом Столе "Properties['Update Criteria']" , правда ведь, Ваше Высочество? :)
>>>Аксесс с этим не справится, у него документированный максимум 4 Мб, а рекомендуемый - 2 Мб.
Ну хотя бы не при детях..
Они ведь могу поверить в эту новость десятилетней свежести..Сообщение не подписано |
|
03-03-2005 10:59сообщение от автора материала Доброе утро. Я думал, эта тема давно умерла - много лет уж прошло. Постараюсь на все ответить. Вопросов много, поэтому буду краток. Некоторые ответы из-за краткости могут показаться резкими, пожалуйста, не обижайтесь.
Введение: господа, вы не подозреваете, какие проблемы возникают при связи Oracle-SQL Server. А какие при связи Oracle-Paradox!!! Делайте все без наворотов конкретных СУБД, пользуясь только тем, что дает стандарт SQL и проблем у Вас не будет.
Вопрос: Автоинкременты превратились в простые поля.
Ответ: SQL-Server нет понятия "счетчик", и это не его вина - это стандарт. Особенно эффективно это решено в Oracle - там есть таблица последовательностей и хранимая процедура, вызывающая новое значение. В SQL-Server нужно ручками реализовать такой же метод.
Вопрос: Все индексы и ключи проигнорированы.
Ответ: Разумеется. В Аксессе индексы - собственная структура, не отвечающая требованиям стандарта SQL. Поправить ручками недолго и несложно.
Вопрос: Access допускает одинаковое имя ключа в разных таблицах, а MSSQL – нет.
Ответ: см. предыдущий, это стандарт.
Вопрос: Пришлось переделывать кучу запросов, содержажихся в программе.
Ответ: Если писать запросы в стандарте SQL, то не придется. Аксесс, как и каждая СУБД вправе использовать свои расширения, но без гарантий совместимости.
Вопрос: First/Last напрочь отсутствует, - чем заменить я пока не понял : (
Ответ: First/Last - расширения Jet. Не соответствуют стандарту SQL. Вопрос решается присоединяемым запросом на Max-Min. На больших наборах данных желательно индексирование таких полей.
Вопрос: агрегатные функции (напр Sum) в JOIN-запросах.
Ответ: ведут себя в соответствии со стандартом SQL.
Вопрос: FLOOR(-1.5) в Query Analyzer.
Ответ: не знаю, я в этом не силен.
Вопрос: Параметры разных типов.
Ответ: Если генерить текст запроса в виде единой строки, проблем не будет. Зато этим вы добъетесь независимости от формата СУБД. Ради этого и существует стандарт SQL.
Вопрос: Ещё непонятно: навигация с серверным курсором заметно медленне, чем с Jet, а на медленных компьютерах просто доходит до неприличия.
Ответ: А то! Серверные курсоры в SQL-Server слишком многое умеют. Поэтому и используются нечасто. А если уже совсем тормозит, это вопрос к параметрам ADO-компонентов Дельфи.
Совет: расчудесная контора Core Labs существует уже более 10 лет. Она занимается одним единственным делом - компоненты для доступа к даннм. АДО конечно хорошо, но это супер-профессионалы. Добро пожаловать: http://www.crlab.com/
Резюме: повторю Ваши золотые слова.
Несмотря на моё ворчание вроде как получилось всё "притереть" и сделать приложение универсальным, которое одинаково работает и на Access и на SQL Server. В итоге отличия свелись только к текстам запросов. А поскольку они формировались динамически, то при рациональном алгоритме всякие там подмены функций и пр. заняли совсем небольшой кусок кода.
Уточнение: совсем небольшой, ну очень маленький.
Info: в описываемом проекте размер базы данных сейчас составляет 780 Мб, количество реальных записей в таблицах доходит до 350 тысяч и больше. Аксесс с этим не справится, у него документированный максимум 4 Мб, а рекомендуемый - 2 Мб.
Info №2 с учетом прошедших лет: Access переводится как "доступ". Для этого он и предназначен, тем более теперь, когда SQL-Server может работать даже под Win98. Сейчас Access - это средство для аналитических задач.
Info №3: в Майкрософте работают не боги. Низкий поклон таким как они, что мы не работаем с базами данных средствами Ассемблера.
Примечание: все вышесказанное является личным мнением и не претендует на истину.
С уважением,
Виктор Светлов. |
|
02-03-2005 08:15>>>А почему же они должны быть одинаковыми? Как никак два принципиально разных продукта
Тут надо было бы набросать цитат от Microsoft, но я беллетристику не коллекционирую.
Воообще, в целом, лично меня раздражает тот факт, что три продукта одного производителя (Access, SQL Server, FoxPro) имеют три OLE DB Provider`а того же производства и соответствующие ODBC-драйверы, этот же производитель предлагает универсальную технологию ADO и во всех системах есть один и тот же "стандартный" набор одинаковых функций, которые можно исп в запросах (аналогичные функции есть и в екселе, и в бейсике), и всё это предназначено не для внутреннего использования а для массового потребителя, т.е. для меня. Так какого лешего я должен искать у черта на рогах описание этих функций для каждого драйвера (а у каждого свои выверты, а в стандартных доках описаний нет). На фоне деклараций о легком обмене данными (и учитывая широкое распостранение этих ситем) это выглядит оч плохо. И синтаксис тот же, и функции те же, ан нет – бейся методом тыка над примитивной задачкой.
Имхо, ничего не мешало стандартизировать имена и параметры таких функций для ODBC и OLE DB Provider`ов. И сэкономить кучу времени и нервов массовых потребителей, т.е. моих.
>>>По правилам работают — если встречается неопределенное значение, то и сумма будет неопределена
Это-то понятно, но данный фрагмент написан именно потому, что были выявлены совершенно разные результаты в Jet и SQL одного и того же сложного многоэтажного запроса именно по указанной причине (null/0). К сожалению, подробно разобрать ситуацию сейчас нет возможности, но тут у меня получился конкретный "камень" (потому и написал, - может кому-то ещё удастся избежать подобных граблей)
>>> параметры создаются по умолчанию строкового типа
>>>А почему строкового?
Для Jet можно написать
ADOQuery1.SQL.Text := 'PARAMETERS IdParam INT;SELECT * FROM Authors WHERE ID=[IdParam]';
Параметр типа INT тебудет создан автоматически:
ADOQuery1.Parameters[0].DataType = ftInteger
Так же для дат и дробных чисел, поэтому выполнять запросы можно без лишнего кода и преобразований, не заботясь о формате представления дат и чисел.
Если же писать так:
ADOQuery1.SQL.Text := 'SELECT * FROM Authors WHERE ID=?';
то
ADOQuery1.Parameters[0].DataType = ftWideString
И заботы вновь появляются.
Собсно параметр создается чуть «ниже» - объектом ADO Command. В последнем случае он имеет тип OleString.
Тогда при передаче Command.Parameters[0].Value = Date дата преобразуется в строку как бог на душу положит, что приводит к ошибке.
Это, конечно, всё ерунда. Но у меня просто все запросы модификации генерились и отправлялись на централизованное выполнение в виде текст+вариантный массив параметров.
Пример:
Command.CommandText := ' PARAMETERS ddd DateTime, rrr IEEEDouble;DELETE FROM AUTORS WHERE ((Birthday>[ddd]) AND (Rating<[rrr]))'; // Command : _Command;
Command.Execute(v, VarArrayOf([Now,0.9]), adCmdText or adExecuteNoRecords);
VarArrayOf([Now, 0.9]) – это параметры, никаких приеобразований не требуется
А вот это вызовет ошибку:
Command.CommandText := 'DELETE FROM AUTORS WHERE ((Birthday>?) AND (Rating<?))'; // Command : _Command;
Command.Execute(v, VarArrayOf([Now,0.9]), adCmdText or adExecuteNoRecords);
ЗЫ
Несмотря на моё ворчание вроде как получилось всё "притереть" и сделать приложение универсальным, которое одинаково работает и на Access и на SQL Server. В итоге отличия свелись только к текстам запросов. А поскольку они формировались динамически, то при рациональном алгоритме всякие там подмены функций и пр. заняли совсем небольшой кусок кода.
Сообщение не подписано |
|
01-03-2005 10:26>>>Пришлось переделывать кучу запросов, содержажихся в программе. В основном, это это пришлось делать из-за разных функций. Всё разное!
А почему же они должны быть одинаковыми?
Как никак два принципиально разных продукта.
>>>Например в MSSQL, как-то непонятно работают агрегатные функции (напр Sum) в JOIN-запросах:
По правилам работают — если встречается неопределенное значение, то и сумма будет неопределена. NULL это не ноль, это ничего
И его нельзя ни с чем складывать.
Если я не ошибаюсь, такое поведение включено с 7-й версии Sql Server'а.
>>>Заменил всё на вопросы: .. WHERE Id=? Тут все параметры создаются по умолчанию строкового типа
А почему строкового? |
|
01-03-2005 09:38Продолжение
А вот по-настоящему неприятный сюрприз, внимание (!!!):
FLOOR(-1.5) в Query Analyzer выдает –2 в полном соответствии с показаниями Book Online,
а через OLE DB Provider for SQL Server FLOOR(-1.5) выдаёт 2 (!!!!)
Это ведь как влететь можно..
На единичных операциях, операциях с положительными числами можно сколь угодно долго пребывать в счасливом неведии, не подозревая о такой бомбе. А потом сформировать какой-нибудь годовой отчет какого-нибудь банка.. Застрелиться лучше сразу..
(Не знаю, может там какой-то режим переключить надо?.. Но тем не менее..)
Сколько есть ещё таких пакостей?.. Не знаю..
Параметры
С Jet можно было задавать параметры и их тип непосредственно в тексте запроса, что избавляло от лишнего кода в дальнейшем:
PARAMETERS ddd DateTime, bbb IEEEDouble;SELECT …
Тогда параметры автоматически создаются сразу нужного типа, и можно было передавать даты и дробные числа без всяких конвертаций.
В SQL такой фокус не прокатывает. Заменил всё на вопросы: .. WHERE Id=?
Тут все параметры создаются по умолчанию строкового типа, и опять начались заботы с преобразованием типов и настройкой параметров..
Дату в строку сделал так: FormatDateTime('"{ d ''"yyyy"-"mm"-"dd"'' }"', SomeDateTime)
Ну и так далее..
Ещё непонятно: навигация по НД с серверным курсором заметно медленне, чем с Jet, а на медленных компьютерах просто доходит до неприличия. Непонятно, будем разбираться.
Видимо, этот перечень можно продолжать ещё долго, но я, пожалуй, ограничусь этим.
А мораль сей басни такова: "легкий переход" гарантирован только для "SELECT * FROM TableName"
Сообщение не подписано |
|
01-03-2005 09:36Вот кой-какие заметки чайника по теме.
Понадобилось перевести небольшое приложеньице с
Access (mdb+Jet+ADO)
на
MS SQL Server. (OLE DB Provider for SQL Server + ADO)
Начитавшись msdn с обещаниями “легкого перехода”, прочел эту статью, и решил, что за пару присестов получиться перейти от одного продукта к другому. Как никак – близкие родственники.
Однако всё обернулось затянувшейся эпопеей без конца и края..
Вот некоторые моменты..
Конвертация из Access – мастер преобразования в формат SQL Server работать отказался – тихо сказал "Overflow" и всё..
Утилита импорта самого SQL Server перетянула базу без лишних вопросов, НО:
1) Автоинкременты превратились в простые поля
2) Все индексы и ключи проигнорированы
Микрософт просто поражает: на кой делать "мастeра", которые не работают? Править вручную все таблицы или запросы CREATE TABLE – это уж слишком..
Пришлось быренько состряпать свой конвертер на базе ADOX.
Переносились только таблицы с данными, ключи и индексы.
Структура таблиц читалась/создавалась с помощью ADOX, а данные переносились запросами INSERT INTO.
И тут не всё так гладко, как хотелось бы.
На что наткнулся:
1) Тип данных
adDate {=7}/ (DBTYPE_DATE)
пришлось менять на
adDBTimeStamp {=135}/ (DBTYPE_DBTIMESTAMP)
2) Access допускает одинаковое имя ключа в разных таблицах, а MSSQL – нет
В конвертере тупо пририсовал к имени ключа имя таблицы.
2) Access допускает имена таблиц и ключей, начинающиеся с цифры, а MSSQL – нет.
Импорт данных с помощью провайдера OLE DB Provider for SQL Server не удался:
ни в какую не захотел он открывать акцессовскую базу, что-то толкуя про разрешение на доступ. Текст запроса типа такой:
INSERT INTO TableName
SELECT * FROM OPENDATASOURCE(''Microsoft.Jet.OLEDB.4.0'', ''User ID=Admin; Mode=3;Data Source="\\MyComp\c\MyDir\MyFile.mdb";'')...MyTable
Чего там не так – не знаю (никаких паролей и левых подключений не было).
Зато со стороны Access через Jet экспорт прошел без проблем:
INSERT INTO TableName IN "" [ODBC;DRIVER={SQL SERVER};SERVER=SERVERNAME;DATABASE=mydatabase;UID=SomeName;PWD=]
SELECT * FROM TableName
При этом все значения в полях типа «счетчик» сохранились.
Да, кстати, создать БД на SQL Server с помощью ADOX нельзя: метод Catalog.Create провайдером не поддерживается. Зато можно выполнить запрос CREATE DATABASE...
через обычное ado-подключение.
Самое противное:
Пришлось переделывать кучу запросов, содержажихся в программе.
В основном, это это пришлось делать из-за разных функций. Всё разное!
First/Last напрочь отсутствует, - чем заменить я пока не понял : (
IIF пришлось менять на CASE’ы и COALESCE, Sgn на Sign, и т.д. и т.п.
Есть еще неприятные моменты, которые могут оказаться «камнями». Например в MSSQL, как-то непонятно работают агрегатные функции (напр Sum) в JOIN-запросах: если считать нечего (выборка пуста) в Jet возвращает ноль, а от SQL Server получаем null, хотя то же самое в простом запросе выдает таки ноль.. Этот null при дальнейших операциях на других уровнях запроса выдает цепочку null-значений, если не делать проверок.
Сообщение не подписано |
|
01-03-2005 05:29| Может кто-нибудь подсказать ресурся по данной тематике. Предстоит работа по переводу баз с локальных Access на SQL север с клиентами на Access |
|
12-01-2004 19:23Один вопрос, если тема еще жива... :)
Я так и не понял одной вещи.
Была БД на Access.
Сделали БД на SQL Server.
Это понятно.
На чем работали клиенты с БД-Access ?
На чем работали клиенты с БД-SQLServer ?
Что на рабочих местах стояло/стало?
Догадываюсь что стояли Access`ы,
ну а дальше на чем?
На тех же Access`ах?
И ничего не пришлось менять?
Ни формочек, ни запросов, совсем ничего???
Т.е. обычные клиенты ничего не заметили?
Или как?
Очень прошу,
Объясните!
У меня сейчас та же задача стоит... |
|
24-11-2003 03:54| Спасибо!Статья попала в самую точку! Если бы я ее не нашел, то провозился бы с переводом очень долго |
|
17-01-2003 00:03Блин, если бы я эту статью вчера прочитал, щас бы уже спал!
А сегодня перекинул, делфи только int and bit видит, vb тоже!
в десятом только домой собрался!Сообщение не подписано |
|
01-01-2003 20:37Для Виктор Светлов и Alex
SQL сервер 7 и выше может делать бакапы на любой девайс если ОС может с ним работать, в том числе и на сетевой диск (или папку).
Имя файла бакапа может бить указано так
X:\DirName\BkpFileName.Bkp
\\ShareName\BkpFileName.Bkp
Чтобы такое стало возможным нужно запустить службу MSSQLSERVER под бюджетом пользователя (например, Администратора) у которого есть права доступа к нужному сетевому ресурсу.
Осторожно, служба MSSQLSERVER имеет по дефолту права LocalSystem,
Нужно чтобы бюджет, под которым она будет работать, имел достаточно прав для доступа к файлам на самом сервере |
|
18-09-2002 13:05<<Последнее, с чем я столкнулся - это особенность работы функции Str() в запросе, которою я использовал для получения строкового значения логического поля. Access давал результат ' -1' и ' 0' для true и false соответственно. SQL-Server предложил ' -1' и ' 0' - уже с 10 пробелами перед значением. Это просто решается с помощью функции LTrim().>>
Функция Str имеет параметры
Syntax
STR ( float_expression [ , length [ , decimal ] ] )
Если вызвать Str(BitField,1,0) то все будет ОК. |
|
10-01-2002 17:59Хотелось бы сделать маленькую поправку насчёт возможности
архивирования в MSSQL на другие носители, кроме локальных дисков.
Я на 100% знаю что в MSSQL 2000 есть возможность архивировать куда-угодно (кроме, разве что перфоленты:)) ,т.к. сам регулярно пользуюсь этой 'уникальной возможностью'.И практически уверен что в 7.0 также есть, иначе тем у кого нет стриммера пришлось бы хранить копии на локальной машине-странно, по-моему.
И ещё одно замечание: автоматическое присваивание типа nvarchar при
создании таблиц в DTS Import Wizard. Если нет особой надобности в использовании Unicode, его следует исправлять на varchar хотя бы потому, что места в раза меньше, а для полей типа text- это важно, вроде.
|
|
10-01-2002 11:13А меня была такая запинка (одна из...) Функция CStr в запросе пришлось поменять аж на (SELECT CONVERT CHAR(4) AS имя_поля ... и что там еще точно не помню), плюс некоторые имена полей которые в Access нормально хаваются, в SQL попали в зарегистрированный диапазон ключевых слов.
Но в целом проблем ни в пример меньше чем с написанием простенького кода на DHTML. Ненавижу JScript, а никуда не денешься. |
|
11-07-2001 17:45Сергею:
Спасибо за консультацию по датам - видно вы специалист :) Я уже сам доехал. Перехожу на обычные.
Сообщение не подписано, не знаю почему. Сайт глючит.
Что касается транзакций, то при использовании трехзвенной клиент-серверной структуры в Дельфи, (DataBase // RamoteDataModule-TDatabase-TQuery // TClientDataSet) транзакция эмулируется виртуально, поэтому никаких сложностей в плане выдергивания сетевого провода не возникает,
несмотря на открытие транзакции у TDatabase.
На днях тестировал SQL 2000. Он отключает зависшие транзакции через 10-20 секунд после халта клиента. До Оракла, конечно, не достать, но третий сорт не брак. Так что буду переходить на ADO и двухзвенную структуру.
Виктор Светлов |
|
09-07-2001 10:48Виктору Светлову
'Как оказалось, в таблице имелась куча записей с годами вроде 2089, 2095, 2099. Причина этого понятна - использование маски при некорректной настройке формата даты в системе. Непонятно, почему эти данные не принял SQL-Server.'
Скорее всего Вы использовали для даты тип smalldatetime, который имеет ограничения:
Date and time data from January 1, 1900, through June 6, 2079, with accuracy to the minute. smalldatetime values with 29.998 seconds or lower are rounded down to the nearest minute; values with 29.999 seconds or higher are rounded up to the nearest minute.
Не подписавшему сообщение
'Применительно к версии 7.0 и ниже АDO имеет большой недостаток в части транзакций. Попробуйте начать транзакцию, сохранить запись и вынуть сетевой провод из клиентского компьютера. Транзакция останется и запись будет блокирована, пока вручную процесс не будет убит.'
Увы, это можно сделать и через BDE. Разницы практически нет.
|
|
05-07-2001 15:22| Если коротко, то тема хорошая, но сказанно мало. |
|
05-07-2001 08:40Портосу
Я рассматриваю этот вопрос. На выходные буду изучать SQL-сервер 2000. (На момент перевода не было инсталляции).
Применительно к версии 7.0 и ниже АDO имеет большой недостаток в части транзакций. Попробуйте начать транзакцию, сохранить запись и вынуть сетевой провод из клиентского компьютера. Транзакция останется и запись будет блокирована, пока вручную процесс не будет убит. У Оракла в этом случае все незаконченные транзакции данного клиента будут отменены автоматически.
К тому же, использование ODBC и BDE дает возможность использовать стандартные компоненты доступа к данным, что важно при быстром переходе из одного формата на другой.Сообщение не подписано |
|
05-07-2001 06:51Настоятельно рекомендую при работе с датабазами от MS переходить на ADO. Связка BDE-ODBC не только тормозна, но и крива. Для Access имеется родной провайдер MS Jet, Для MS SQL - тоже свой провайдер.
Увеличение производительности поразительно. Причем переходить ведь можно постепенно, от связки ADO->ODBC. Хотя это почти тоже самое, что рубить собаке хвост в несколько приемов. |
|
03-07-2001 11:26У меня был следующий опыт:
Из MS Access в MS SQL Server 7.0 была переброшена таблица имеющая на тот момент порядка 1 миллиона записей (из 4-х полей). Данная таблица была единственной во вновь созданной базе. Был создан уникальный индекс. Прилинковав таблицу в MS Access обнаружил, что открытие этой таблицы вместо мгновенного стало затягиваться на 30 секунд, и при скролинге задержки тоже присутствуют. :( Это проблема кривых рук? Может надо индексы создавать внимательно, а не default или еше что-то. |
|
|
|
