Всем привет!

1. про view, ну конечно тащить на клиента всю таблицу смысла нет, поэтому:

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

ограничение №2(параметр2) - временной период, разумеется необходим, запись введена сегодня -> она получает сегодняшнюю дату, прошу не путать занесение новой записи и работу состарыми записями(редактирование). Вопрос был как получить id новой записи, не так ли?

ограничение №3(параметр3) - могут быть другие параметры, зависит от типа задачи..

2.было предложенно что-то типа:
sqlexec(cn,'insert into ... ;SELECT SCOPE_IDENTITY() as SCOPE_IDENTITY',crsr)
но перед этим необходимо получить cn, значит
sqlconnect(connect) потом sqldisconnect(cn)
ну и масса других лишних обращений к серверу..
в моем случае все проще, requery - это:
sqlexec(cn,'insert into ... ;SELECT SCOPE_IDENTITY() as SCOPE_IDENTITY',crsr)
выполненое пакетом на сервере.

3. /*Конечно часто упорядочение
делают уже на клиенте (временные индексы) - НО и тогда эта схема точно
разрушается.*/ вот этим никогда не пользуюсь, есть плохой опыт..

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

Aleksey-KВ дополнении к замечаниям PaulWist и ВладимирМ для FoXXX:
А если нет кластерного индекса, данные лежат в HEAP - куче, т.е. страницы по 8 кб, связанные ТОЛЬКО через специальные страницы IAM (Index Allocation Map). Это означает, что при операции вставки, удалении и тем более при SHRINK (при сжатии базы данных) может происходить ФИЗИЧЕСКОЕ перемещение записей внутри страницы, что приводит к ДРУГОМУ порядку расположения и ИЗВЛЕЧЕНИЯ данных сервером с диска в кэш, ну и затем клиенту.

С уважением, Алексей

ну чтож, проведем эксперимент:
создадим простенький view:

SELECT Proba.id, Proba.time, Proba.kod;
FROM ;
dbo.proba Proba

DBSetProp(ThisView,"View","SendUpdates",.F.)
DBSetProp(ThisView,"View","BatchUpdateCount",1)
DBSetProp(ThisView,"View","CompareMemo",.T.)
DBSetProp(ThisView,"View","FetchAsNeeded",.F.)
DBSetProp(ThisView,"View","FetchMemo",.T.)
DBSetProp(ThisView,"View","FetchSize",-1)
DBSetProp(ThisView,"View","MaxRecords",-1)
DBSetProp(ThisView,"View","Prepared",.F.)
DBSetProp(ThisView,"View","ShareConnection",.F.)
DBSetProp(ThisView,"View","AllowSimultaneousFetch",.F.)
DBSetProp(ThisView,"View","UpdateType",1)
DBSetProp(ThisView,"View","UseMemoSize",255)
DBSetProp(ThisView,"View","WhereType",1)

DBSetProp(ThisView+".id","Field","DataType","I")
DBSetProp(ThisView+".id","Field","UpdateName","dbo.proba.id")
DBSetProp(ThisView+".id","Field","KeyField",.F.)
DBSetProp(ThisView+".id","Field","Updatable",.F.)

DBSetProp(ThisView+".time","Field","DataType","T")
DBSetProp(ThisView+".time","Field","UpdateName","dbo.proba.time")
DBSetProp(ThisView+".time","Field","KeyField",.F.)
DBSetProp(ThisView+".time","Field","Updatable",.F.)

DBSetProp(ThisView+".kod","Field","DataType","I")
DBSetProp(ThisView+".kod","Field","UpdateName","dbo.proba.kod")
DBSetProp(ThisView+".kod","Field","KeyField",.F.)
DBSetProp(ThisView+".kod","Field","Updatable",.F.)

далее прогоним код:
USE proba IN 0
SELECT proba
FOR i=0 TO 1000
APPEND BLANK
REPLACE time WITH datetime(), kod WITH 1
ENDFOR
=TABLEUPDATE()
FOR i=0 TO 1000
APPEND BLANK
replace time WITH dateTIME(),kod WITH 2
ENDFOR
=TABLEUPDATE()

посмотрим что в таблице:

все лежит по-порядочку и по времени и по дате,
далее, зайдем в SQL Server Enterpris, глянем на табличку
SELECT *FROM proba - все по порядочку, далее сделаем shrink ,смотрим - все попорядочку...
открываем вью, все упорядочено..
чтобы нам еще сделать такое, чтобы нарушить порядок записей????
думаем...
не выходит, но ведь это КУЧА!!! просто КУЧА!! не так ли? интересно в этой куче поля не перемешиваются??? а буквы в словах?? страшное слово КУЧА!!!

вспомним файловую систему, как лежат байты в секторах и кластерах??? и понимаем, что любой файл есть не куча- а структура, т.е. информация структурирована, иначе это не файл а куча дйствительно... можно ли вставить запись внутрь файла? можно, но нужно пол файла переписать, так зачем это делать, ресурсов много?? потому новая запись в конец структуры, и нет никакой кучи, работает быстро, и байты не перемешиваются...
да, а как же /*специальные страницы IAM (Index Allocation Map). */??? ну здесь не мешало бы вспомнить принцып работы контроллера жесткого диска, выделение памяти... итак память выделена(создан буфер), далее головка контроллера двигается к кластеру №х и... чик, буфер полон, выделяем следующий буфер.. и чик, буфер полон, вот они страницы IAM.... и т.д.
А допустимо ли перемешивание информации????? ДА!!! Допустимо!!! Если у разработчиков системы в голове КУЧА!!! Если нет.. то не допустимо...

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

так что Алексей, ПаУль и ВладимирМ ... ваши представления нуждаются в корректировке... или не так?

Да, а если взглянуть на поднятый атором топика вопрос, важно ли это (куча)?
Не важно, потому что записи упорядочены по id, view имеет order, так зачем было нужно поднимать этот вопрос ???

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

Aleksey-KВ дополнении к замечаниям PaulWist и ВладимирМ для FoXXX:
А если нет кластерного индекса, данные лежат в HEAP - куче, т.е. страницы по 8 кб, связанные ТОЛЬКО через специальные страницы IAM (Index Allocation Map). Это означает, что при операции вставки, удалении и тем более при SHRINK (при сжатии базы данных) может происходить ФИЗИЧЕСКОЕ перемещение записей внутри страницы, что приводит к ДРУГОМУ порядку расположения и ИЗВЛЕЧЕНИЯ данных сервером с диска в кэш, ну и затем клиенту.

С уважением, Алексей

ну чтож, проведем эксперимент:
создадим простенький view:

SELECT Proba.id, Proba.time, Proba.kod;
FROM ;
dbo.proba Proba

DBSetProp(ThisView,"View","SendUpdates",.F.)
DBSetProp(ThisView,"View","BatchUpdateCount",1)
DBSetProp(ThisView,"View","CompareMemo",.T.)
DBSetProp(ThisView,"View","FetchAsNeeded",.F.)
DBSetProp(ThisView,"View","FetchMemo",.T.)
DBSetProp(ThisView,"View","FetchSize",-1)
DBSetProp(ThisView,"View","MaxRecords",-1)
DBSetProp(ThisView,"View","Prepared",.F.)
DBSetProp(ThisView,"View","ShareConnection",.F.)
DBSetProp(ThisView,"View","AllowSimultaneousFetch",.F.)
DBSetProp(ThisView,"View","UpdateType",1)
DBSetProp(ThisView,"View","UseMemoSize",255)
DBSetProp(ThisView,"View","WhereType",1)

DBSetProp(ThisView+".id","Field","DataType","I")
DBSetProp(ThisView+".id","Field","UpdateName","dbo.proba.id")
DBSetProp(ThisView+".id","Field","KeyField",.F.)
DBSetProp(ThisView+".id","Field","Updatable",.F.)

DBSetProp(ThisView+".time","Field","DataType","T")
DBSetProp(ThisView+".time","Field","UpdateName","dbo.proba.time")
DBSetProp(ThisView+".time","Field","KeyField",.F.)
DBSetProp(ThisView+".time","Field","Updatable",.F.)

DBSetProp(ThisView+".kod","Field","DataType","I")
DBSetProp(ThisView+".kod","Field","UpdateName","dbo.proba.kod")
DBSetProp(ThisView+".kod","Field","KeyField",.F.)
DBSetProp(ThisView+".kod","Field","Updatable",.F.)

далее прогоним код:
USE proba IN 0
SELECT proba
FOR i=0 TO 1000
APPEND BLANK
REPLACE time WITH datetime(), kod WITH 1
ENDFOR
=TABLEUPDATE()
FOR i=0 TO 1000
APPEND BLANK
replace time WITH dateTIME(),kod WITH 2
ENDFOR
=TABLEUPDATE()

посмотрим что в таблице:

все лежит по-порядочку и по времени и по дате,
далее, зайдем в SQL Server Enterpris, глянем на табличку
SELECT *FROM proba - все по порядочку, далее сделаем shrink ,смотрим - все попорядочку...
открываем вью, все упорядочено..
чтобы нам еще сделать такое, чтобы нарушить порядок записей????
думаем...
не выходит, но ведь это КУЧА!!! просто КУЧА!! не так ли? интересно в этой куче поля не перемешиваются??? а буквы в словах?? страшное слово КУЧА!!!

вспомним файловую систему, как лежат байты в секторах и кластерах??? и понимаем, что любой файл есть не куча- а структура, т.е. информация структурирована, иначе это не файл а куча дйствительно... можно ли вставить запись внутрь файла? можно, но нужно пол файла переписать, так зачем это делать, ресурсов много?? потому новая запись в конец структуры, и нет никакой кучи, работает быстро, и байты не перемешиваются...
да, а как же /*специальные страницы IAM (Index Allocation Map). */??? ну здесь не мешало бы вспомнить принцып работы контроллера жесткого диска, выделение памяти... итак память выделена(создан буфер), далее головка контроллера двигается к кластеру №х и... чик, буфер полон, выделяем следующий буфер.. и чик, буфер полон, вот они страницы IAM.... и т.д.
А допустимо ли перемешивание информации????? ДА!!! Допустимо!!! Если у разработчиков системы в голове КУЧА!!! Если нет.. то не допустимо...

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

так что Алексей, ПаУль и ВладимирМ ... ваши представления нуждаются в корректировке... или не так?

Да, а если взглянуть на поднятый атором топика вопрос, важно ли это (куча)?
Не важно, потому что записи упорядочены по id, view имеет order, так зачем было нужно поднимать этот вопрос ???

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

Sorry for double message, my internet connection is fucking bad...

Hi, Igor Korolev!
Even if our names are same, I have my own opinion. And I think I have this right.

Greetings to sunny Belarus! I was in Mogelev region in July 2005, visiting my relatives. I'd liked it. It is exelent in culture. Streats are clean, greenhedges and bushes are cutted.
I wish you success in learning personal computer...

8<--------------------------------------------------------------------------

Bonjour, Igor!
Je m'appele Igor et tu es appeles Igor aussi.
Mes Je voudrais parler tu mon opinion n'est pas pareil et j'ai un vraiment.
Je desire tu succes a l'etude de computer personal.

Aleksey-KДа.. батенька... это у вас в голове куча. Вы для начала почитайте BOL о структуре хранения данных MS SQL Server 2000 (хотя и SQL 7.0 годится).
Heap в понятии SQL Server это набор СТРАНИЦ данных, а не байт!
Да, внутри страницы данные могут при операциях перемещаться ФИЗИЧЕСКИ, но это всего-навсего 8192 байта (1 страница = 8КБ). А сами страницы данных (и индексов) связаны ТОЛЬКО через IAM и, разумеется, ни куда не перемещается физически (кроме операций типа DBCC SHRINKDATABASE и пр.).
А для того, чтобы увидеть изменения в порядки извлечения данных из таблицы в вашем примере надо заставить сервер этот порядок поменять физически, например:
Постройте кластерный индекс, скажем, по полю time DESC или, что лучше и нагляднее: добавьте поле типа VARCHAR(1000) DEFAULT '' и попробуйте заполнять это поле данными под завязку в разных строках (а не у всех и все одинаково), а потом смотрите в каком порядке будет сервер извлекать данные по сравнению с первоначальным.

С уважением, Алексей

поменять физически... мнда... физичесики поменять можно.. получается SQL производит не индексацию таблицы, не построение индексного ключа, а осуществляет сортировку... т.е. физическую сортироку записей... но ведь это откат, может это и оправданно, но.. мы от этого в DBF отказались давно..
если в SQL действительно используется метод сортировки (физического упорядочения записей), то порядок следования записей действительно изменится..

с другой стороны, а зачем нам все это нужно???

мы ведь просто хотим видеть id сразу после вставки новой записи, к чему лезть в дебри??

Залезть в BOL оно конечно можно, но чесслово - лень..
ну не в этом суть.. пример вам я прогнал, впринципе порядок соблюдается, зачем копать MSSQL если используется кей по id?
он используется везде по умолчанию, на мой взгляд это логично, нужен другой порядок -пжалуста ORDER.. в select..

/*И не кому не говорите,что:*/ - я не говорю, а скорее, рассуждаю о принципах организации базы данных, так сказать отвлеченно, ничего конкретно при этом не утверждая, потому и не ссылаюсь на BOL..

если возникнет конкретный вопрос о дебрях базы - будем разбираться предметно, думаю не мало накопаю интересного, но в данный момент это будет уход от темы.. др. словами флуд..

вот если бы вы раскрыли мне почему перезапрос не приемлем в данном случае, я был бы вам благодарен, но ничего конкретного небыло сказано ни игорем ни вами, так - общие слова: так не пишем, так не программируем.. вся критика свелась к промежутку tableupd() и requery(), ну убрал я, как в самом начале сказал, tableupd(), оставил requery(), и что? шквал критики не прекратился - усилися но не по существу к сожалению..

в ваших рядах убыло сегодня, однако, суббота, вы по выходным трудитесь?

вашим сайт иногда, по мере необходимости использую, спасибо.


С уважением FoXXX.

FoXXXвашим сайт иногда, по мере необходимости использую, спасибо.


С уважением FoXXX.

извиняюсь, очепятка, ваш сайт разумеется..

С уважением FoXXX

ВладимирМ FoXXX
Здесь я вычеркнул массу слов, которые обычно заменяются звуковым сигналом или многоточием.

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

http://www.sql.ru/articles/mssql/03013101Indexes.shtml

Там в самом начале показывается как физически хранятся данные в MS SQL.

Если Вы считаете, что ВСЕ отвечавшие Вам заблуждаются, то задайте свой вопрос в форуме по MS SQL на этом же сайте. Ведь Ваш вопрос не имеет к FoxPro никакого отношения. Это именно вопрос способа хранения в MS SQL.

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

пример работает, но это не факт что он будет работать в любом случае, возможно при определенной ситуации он работать не будет..

и что вы так нервничаете? к чему все эти многоточия?? еще раз напоминаю вам что тема топика другая, вопрос не в способе хранения данных в SQL, вопрос в получении id. Кстати вопрос по хранению данных на SQL я не поднимал, это скорее ваш вопрос (или ваших единомышленников) лень перечитывать всю дискуссию.. Именно не я начал обсуждение: как же хранятся данные на SQL, я лишь предложил использовать requery() и не более того, но как видно вас раздражает любое мнение отличное от вашего, мне жаль, что вам хочется чередовать свою речь многоточиями.. чесслово не хотел лично вас обидеть, да и вообще никого не хотел обижать. Если говорить о хранени я лишь высказал общие принципы хранения данных (любых) в файловой системе DOS или Windows, помоему ничего крамольного?

если я упомянул о последней записи, то говорил скорее о VFP, т.к. в нем я применяю те же методы обновления информации как и в SQL, что удобно, т.к. иногда мои системы работают без SQL с таблицами VFP. Практически без изменений в коде моя система может быть развернута и в SQL и в VFP.. достаточно в базе сформировать (подключить) таблицы или RV с совпадающими названиями.

вот о методе как раз по подробней и хотел бы услышать критику, а по поводу физического хранения - вы не правы, мой метод никак на связан с физическим хранением информации..

я уже обьяснял, что мои программы вообще не привязанны к базе, данные можно хранить в MSSQL, ORACLE, VFP.. я добивался универсальности..
вот ваши методы действительно не могут обеспечить универсальности, т.к. коннект каждый раз прописывается и T-SQL отличается от PL-SQL..

работая напрямую с базой получаем "узкую специализацию" программы..

RV - упорядочен по id, кроме того он параметризированный, что обеспечивает всем необходимым для использование requery(), как вы привязываете эту команду к физическому хранению данных непонятно.. requery работает с любыми данными, через ODBC, это уже ODBC разбирается как там на физическом уровне..

/*Переписывать всё равно придётся серверные процедуры тригеры виды.... всю обработку которая на сервере
функции которые вы вставляли в оракл и многое другое работы хватит.
*/

чудес не бывает, для создания баз приходится писать скрипты, для SQL свой, для ORACLE свой... что делать, но прога остается неизменной, все в RV, скрипты пускаем при инсталляции, выбор сервера и создание таблиц, привелегии разумеется нужно иметь, иначе что вы за программист? даже если у вас безопасность на высоте..

клиент же работает только с RV.. в отличие от CAD RV создается единожды, CAD же необходимо создавать в каждой форме, а их > 50...

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

Aleksey-KДа, разумеется, FoXXX ваш подход тоже имеет право на жизнь и работать с сервером ТОЛЬКО через RV можно. Но есть некоторые операции на сервере, которые просто НЕЛЬЗЯ выполнить через RV. Как вы потупаете в таком случае?
С уважением, Алексей

Hi Алексей!

с ходу не могу придумать такой ситуации, подскажите, отвечу..
о каких операциях речь?

ВладимирМ!

В том то все и дело, что вы всевремя говорите о том, что физическое хранение информации не позволяет мне использовать RV во всех случаях..

и главное ничего конкретного, одни общие рассуждения и многоточия, вот и в последнем посте тоже самое, ни слова конкретики..

RV для того и создан, чтобы работать с другими базами и источниками данных кроме VFP.

Сотый раз говорю, зачем нам знать методы работы SQL со своими данными, мы знаем, что SQL или ORACLE присваивает id в соответствии со своими счетчиками, этого достаточно, далее requery() обновляет нам наш курсор, и не важно где данные лежали до этого, в VFP MSSQL ORACLE и т.д. RV упорядочен, т.е. order по ключу (по id), делаем go bottom и попадаем на новую запись с новым id.. может быть ваш метод работает быстрее (хотя я сомневаюсь в этом), но эта скорость не критична в данном случае, мы ведь просто добавили запись и работаем с ней, а не готовим отчет, не строим сложный запрос для аналитики не так ли?

Ну что вам еще сказать, если вы не можете аргументированно отказаться от RView или CAD, то можно только сожалеть об этом.

в конце концов можно ведь дискутировать придерживаясь фактов а не эмоций, иначе это не дискуссия а только показывание пальцев (веером).