|
Страници по тази тема: 1 | 2 | >> (покажи всички)
Тема
|
Za Kromid i ...
|
|
Автор |
Веселина () |
Публикувано | 16.08.00 12:05 |
|
za 21-vija bit.
Zdrasti. Otpuskata svyrshi za syzhalenie i sega otnovo zadachki i proektcheta. Tova koeto prochetoh za 21 bit e slednoto :
Dependency Constants (SQLDMO_DEPENDENCY_TYPE)
SQLDMODep_DRIOnly 2097152 List only SQL Server components that depend on the referenced SQL Server component in a DRI relationship.
Object Scripting Constants (SQLDMO_SCRIPT_TYPE)
Object scripting constants are used by objects and methods that generate a Transact-SQL script as part of an administrative task automated by using SQL-DMO.
Object scripting constants are used in the context established by the object or method. For more information about object scripting constant context, see the reference for the object or method.
SQLDMOScript_SortedDataReorg 2097152 Obsolete.
Replication Script Constants (SQLDMO_REPSCRIPT_TYPE)
Replication script constants control Transact-SQL command batch contents for the Script method of a SQL-DMO object representing a replication component.
SQLDMORepScript_
UninstallReplication 2097152 Command batch includes Transact-SQL statements removing replication components
Script Method (SQL-DMO)
The Script method generates a Transact-SQL command batch that can be used to re-create the Microsoft® SQL Server™ component referenced by the SQL-DMO object.
object.Script( [ ScriptType ] [, ScriptFilePath ] [, Script2Type ] ) as String
Script2Type Optional. A long integer overriding default scripting behavior as described in Settings.
When setting the Script2Type argument specifying multiple behaviors, combine values by using an Or. Use these values to set Script2Type.
SQLDMOScript2_FullTextCat 2097152 Command batch includes Transact-SQL statements creating Microsoft Search full-text catalogs.
Maj ne izleze mnogo chetlivo, no pisha malko byrzichko i na zor.
Leka rabota
Pozdravi Veselina
| |
|
тоя 21-ви имал много значения... в момента, в който се стигне до репликация, най-добре да ти настръхнат косите и да бягаш бързо... ;)
иначе и на теб лека (и нескучна :))
а къде го прочете тва? да не ми е стар MSDN...
| |
|
няма за какво. То това да бягам бързо е гот като идея, ама няма да стане. Това го четох в хелпа за библиотечката. Та мойта си базичка беше в Access 2000 и с Upsizing Wizard (може би не най-удачното, но за момента туй сторих) си я прехвърлих на сервера (любим). Предполагам че индексите (и всички обекти) след това като сканирам базата ги възприема като perlication. Я да видим какво ще излезе от цялата работа. Ще продължа борбата.
Мерси пак.
| |
|
оуу, тоя Upsize е олеле мале. Ако имаш алтернатива, пробвай я. Всъщност, кой - тоя, който фърфи със сърфъра или с Access'2000 (или пък тоя с Access'97)? в интерес на истината, МИСЛЯ, че в '2000 е същия, но не съм сигурен, може да са го пооправили
| |
|
дето си върви комплект с акцеса. Гот стана нямам думи, троша си здраво главата. Но все някъде ще му излезе края. Ако пък не ще мисля нещо по-добро
| |
|
ти ако знаеш какъв беше този към SQL Server 6.5 - просто безумен! уникален - не мога да си представя, че някоя фирма може от свое има да пусне такъв source - просто трагедия. Имаше едни алгоритми за имената на обектите - щото 6.5 идентификатора беше до 32 символа - абе, не ти е работа! Много се кефехме вътре на коментарите - щото имаше и коментари... ;)
Проблем може да ти възникне, ако си решила да правиш система, която да ползва като база данни и Access-a, и SQL Server-a. Доколкото си спомням, това е само Upsizer, няма upgrade възможности за структурата, така че не можеш нанасяйки промяна в Access-базата, всеки път да upsize-ваш. Да не говорим пък при краен клиент... Слава Богу, Upgrade на SQL Server база се пише за, айде да не е часове, но за 2 дни се пише, без майтап - писал съм, даже още се ползва тук-там. С SQL-DMO-то, разбира се :).
| |
|
не акцеса няма да го ползвам в системата въобще. Само сервера.
| |
|
ще луднеш от мен. Все въпросчета задавам. Та сега ми се ще да те запитам следното :
има ли начин и какъв е той автоматически куиритата от акцес да ги прехвърля някакси във views? Щото често казано не ми се пишат на ръка. А и логично ми се струва (доколко е така не знам) след като с upsizing да прехвърля базата (само таблиците) да има и нещо подобно за quiries. Ta има ли нещо такова, съвет евентуално за ползването му, ако има, или са се въоръжа с търпение и нерви?
Весето
| |
|
чакай сега - то това не става толкоз лесно... най-малкото, можеш да прехвърлиш само query-тата, които не използват user-defined функции - били те твои или Access-ки, също не можеш да прехвърлиш query-та, които имат обръщения към, да речем, форма - то това се е user-defined функция, на практика. т.е., всички query-та, които имат нещо от типа на:
Select * from Table1 where Id=MyFunction(Field2,Field5)
или
Select * from Table1 where Field7 like Forms![Alabala]![AlabalaControl]
умиргат автоматично. Това може да го знаеш, но може и да не го знаеш, затова го пиша за всеки случай. Просто да не се мориш да се опитваш - теоретично не се връзва с идеята за клиент-сърфър. За тези неща ще ти трябва преписване на ръка, и проблема въобще няма да бъде в преписването на самото query, а преписването на свързания с него код (форма).
Всички query-та, съдържащи ORDER BY клауза, също умират - това, на пръв поглед, не е позволено. На втори поглед се оказва, че можеш да "хакнеш" тази забрана - мога да ти кажа начин, който нито е добър, нито е сигурен, нито е документирано верен - т.е., работи, но по милостта Божия.
Простите query-та мисля, че се прехвърлят 1 към 1, ако това те утешава. Важно е също какъв front-end ще ползваш - Access или VB?
питай, ако не съм ясен някъде.
| |
|
мдааа. Знаех си аз че ще трябва да си пиша здраво. Но тайно се надявах че няма да е така. Ох какво ме чака. Честно казано някои неща не ги знаех. Но ... човек се учи докато е жив, нали?
| |
|
Страници по тази тема: 1 | 2 | >> (покажи всички)
|
|
|