INSERT INTO в MSAccess и MSSQL

[Twister]

Разрабатываю клиент-серверный проект, который будет работать под MSSQL. Но пока я использую MSAccess, а на MSSQL буду переводить, когда все будет готово. Для совместимости этих СУБД стараюсь использовать лишь "кроссплатформенные" запросы, т.е. использую синтаксис SQL, присущий обеим СУБД. И вот возник у меня вопрос:
В MSAccess сделать копию записи в таблице можно таким запросом (проверено - работает):

Код: Выделить всё

INSERT INTO cm_Sale (Name) SELECT Name FROM cm_Sale WHERE id=97

А в справочнике по MSSQL приводиться вот такой вариант (который в MSAccess не работает):

Код: Выделить всё

INSERT INTO cm_Sale (Name) VALUES (SELECT Name FROM cm_Sale WHERE id=97)

Вопрос: будет ли работать первый запрос и в MSAccess и в MSSQL? И если нет, то есть ли "кроссплатформенное" решение?

ЗЫ: Просто пока нет возможности проверить за неимением MSSQL.

[alibek]

А в справочнике по MSSQL приводиться вот такой вариант (который в MSAccess не работает

Странный справочник. Выкинуть нафиг, пользоваться Book Online.
Первый вариант правильный и работать будет почти везде.

[Twister]

Спасибо, alibek. Тебе я поверю наслово...

Но вот если косяки потом попрут - спрошу с тебя...
*It was a joke, don't be angry...

[Twister]

2 alibek

Первый вариант правильный и работать будет почти везде.

А можно узнать, где он не будет работать? Чтоб знать...

[alibek]

Даже не знаю, где это может не работать. Но мало ли.

[Ennor]

А можно узнать, где он не будет работать? Чтоб знать...

Афаик, вариант с Insert Into ... Select - это ANSI-синтаксис, и будет работать в любой БД, которая декларирует хоть какой-то уровень совместимости со стандартом (хотя бы SQL-92). Может запросто не работать в MySQL, ибо сия "тоже СУБД" дюже извратная в плане синтаксиса, и на стандарты класть хотела.

Насчет второго варианта... я не думаю, что он вообще хоть где-то будет работать. Во всяком случае, ни разу подобного изврата нигде не встречал.

И еще: идея переводить на сиквел, когда все будет готово, изначально ошибочна и в лучшем случае приведет к тому, что все так и останется на Аксессе, а в худшем - это будет типичный безнадежный проект. Еще и бесконечный, вдобавок.
Скачай хотя бы MSDE 2000, а еще лучше SQL Server 2005 Express Edition - если проект новый и никакой обратной совместимости от него не требуется, то лучше и средства использовать максимально новые - это обеспечит его (проекта) актуальность в течение максимально длительного времени. В особенности учитывая тот факт, что в MSSQL 2005 появилось немеряное количество всяких принципиально новых фишек, грамотное использование которых может реально улучшить систему.

Разумеется, какое-то время у тебя уйдет на ознакомление с концепцией систем "клиент-сервер", какое-то - на понимание идеологии MSSQL, но... тебе же в любом случае придется это делать. А систем, перенесенных с Аксесса на сиквел, я в своей жизни навидался предостаточно - не советую тебе создавать еще одну, такую же.

[Twister]

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

Слышал когда нибудь про CRM системы? Это уже готовые клиент-серверные решения, которые можно "затачивать" под конкретную фирму с помошью скриптов и плагинов. Вот именно этим я сейчас и занимаюсь. Работаю в демо-версии, которая отличается от нормальной лишь тем, что работает только с MSAccess. А полная работает на MSDE или MSSQL. Поэтому тут, конечно, ты не прав...

Разумеется, какое-то время у тебя уйдет на ознакомление с концепцией систем "клиент-сервер", какое-то - на понимание идеологии MSSQL

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

Тем не менее, спасибо за советы и ответы...

[Ennor]

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

Да, присоединяюсь к совету Алибека выбросить такой справочник по MSSQL.