Здравствуйте, postbald, Вы писали:
P>Ведь для чего то же существует my_db.LDF.
Ну как бы LDF существует вовсе не для этого, а для того, чтобы обслуживать транзакции и иметь возможность восстановть базу в случае каких-либо неприятностей. Для внутренних нужд сервера вообщем.
Но для пытливого ума нет ничего невозможного...
P>Было бы замечательно если была бы возможность смотреть его в таблице,
Возможность есть:
DBCC LOG([dbid[,{0|1|2|3|4}[,['lsn','[0x]x:y:z']|['numrecs',num]|['xdesid','x:y']
|['extent','x:y']|['pageid','x:y']
|['objid',{x,'y'}]|['logrecs',{'lop'|op}...]
|['output',x,['filename','x']]...]]])
SELECT * FROM ::fn_dblog ( default, default )
Но на неокрепшие умы действует пагубным образом, нифига не понятно....
P>или если есть софт который его(лог) показывает , позволяет генерить отчеты.
Есть, LumigentLogExplorer
http://www.lumigent.com
А можно и своё что-нибудь написать на хитрых триггерах... Тоже не самый плохой способ.
Здравствуйте, _MarlboroMan_, Вы писали:
ах да... забыл...
есть еще такая фантастическиудобная штука profiler называется... собственно он мониторит всю активность на серваке.
эта штука позволяет писать инфу в базу.
если уж совсем невмоготу, то посмотри что он может, но если таки решишь пользовать его — закупай винты побольше и вперед.
вообще твоя задача в прямом решении весьма прожорлива до места будет...
... << RSDN@Home 1.0 beta 6a >>
Здравствуйте, postbald, Вы писали:
P>посоветуйте как его создать,открыть...
P>Ведь для чего то же существует my_db.LDF.
*.LDF — журнал транзакций. он собственно не совсем для этого предназначен.
P>Было бы замечательно если была бы возможность смотреть его в таблице,
т.е. ты хочешь иметь, так сказать, копию базы, но "спроецированною на ось времени"??? да еще и в текстовом виде???
хмм... что-то я в жизненоважном деле таким тулзам не доверился бы...
в подобной ситуации
мои действия:
вариант 1.
а не проще просто в таблицы добавить нужные поля что-то типа
ModUser (для хранения ида юзера),
ModDate (соответственно дата/время изменений),
ModType (вид изменений: вставка, модификация, удаление),
Fl_del — false/true (признак того что запись удалена).
далее..
при какой-либо модификации данных вставляешь новую идентичную запись с признаком модификации, а старую метишь как удаленную.
работа всегда ведется только с "живыми" записями.
при нужде строй по своим таблицам соответствующий лог.
вариант 2.
навешать триггеров и из них заполнять лог. но! в данном случае восстановление информации при ее "порче" процес будет
полу-автоматический, а в варианте 1 — можно делать на автомате.
... << RSDN@Home 1.0 beta 6a >>