belemélyedtem a súgóba mégjobban, úgyh, larzentől ezúttal is boccs az ADO-s kérdés miatt! de szerintem fogok feltenni még ilyeneket. :)
mondjuk megoldom azt, hogy a for xml által generált scriptből csinálok vhogy fájlt. (nem az sql server eszközeivel). az export miatt viszont továbbra kérdés marad, hogy egy xml fájlt hogyan nyitok meg az sql server számára, hogy aztán az openXML-lel tudjak operálni vele.
szerintem ez csak http-n keresztül megy, ha jól értem a helpet.
a books online ezt irja:
Retrieving XML Documents Using FOR XML
You can execute SQL queries against existing relational databases to return results as XML documents rather than as standard rowsets. To retrieve results directly, use the FOR XML clause of the SELECT statement, and within the FOR XML clause, specify one of these XML modes:
RAW
AUTO
EXPLICIT
These modes are in effect only for the execution of the query for which they are set. They do not affect the results of any subsequent queries. In addition to specifying the XML mode, you can also request the XML-Data schema.
Továbbá:
Executing Template Files Using HTTP
Writing long SQL queries at the URL can get cumbersome. Instead, templates can be used to specify queries (SQL or XPath). The template file name is specified in the URL. A template is a well-formed XML document containing one or more SQL statements and XPath queries.
Using a template you can:
Specify SQL queries or XPath queries. When XPath queries are specified in the template, the mapping XML-Data Reduced (XDR) schema file against which the query is to be executed is also identified in the template.
Specify a top-level element for the XML fragment that is returned by executing SQL or XPath queries; thereby, making the result of executing the template in the URL a valid XML document.
Define parameters that can be passed to SQL statements or XPath queries.
Declare namespaces.
Specify an Extensible Stylesheet Language (XSL) style sheet to apply to the resulting document.
Template files also enhance security. Because the URLs (and thus the queries in the URL) can be edited, by having the queries stored in a file (template file), you can prevent users from modifying the queries and obtaining information you do not want them to see.
The security is enforced by removing the URL query-processing service on the virtual root and leaving only the MicrosoftŽ SQL Server XML ISAPI to process the files and return the result set. The virtual root is registered using IIS Virtual Directory Management for SQL Server utility.
Before templates can be specified in the URL, the virtual name of template type must be created using the IIS Virtual Directory Management for SQL Server utility. For more information, see Using IIS Virtual Directory Management for SQL Server Utility.
sajnos nem lehet kikerülni ezt a mókát. ebben a szituban mindenképp szükség van rá.
az ADO.NET-es gondolatod egy kósza ötlet volt csupán, v kombinálható a T-SQL-lel? (még elég kezdő vagyok ilyen téren, úgyh lehet, h ez egy hülye kérdés volt...)
az osql.exéről, illetve annak felparaméterezéséről tudnál kicsit többet mondani?
érdekes probléma
semmi nem jut eszembe, hogyan lehetne simplán TSQL-lel bármilyen query resultot elmenteni fájlba. részemről megkerülném a fájlba mentést. Eléggé idegen gondolat programból fájlba menteni adatbázis tartalmat majd visszatölteni. esetleg meg lehet próbálni, hogy osql.exe-t felparaméterezni és az outputját átirányítani...
Ha valami hordozónyelvet használnál, könnyű lenne, pl. az ADO.NET-ben a DataSet-nek van XML író/olvasó metódusa.
a feladat az, hogy adatot exportáljak XML-be, majd onnan vissza az adatbázisba.
ehhez megtaláltam a következő eszközöket: FOR XML, OPENXML, sp_xml_preparedocument, sp_xml_removedocument.
ahogyan az a súgóban írva vagyon...
csak azt nem sikerült kiderítenem, h a FOR XML által generált scriptet hogyan tudom fájlként menteni, illetve ha importhoz az OPENXML-t akarom használni, akkor előtte hogyan nyissam meg azt a fájlt, ami az importálandó adatokat tartalmazza.
esetleg az XML Bulk Load-ot kellene használnom? ez esetben is felmerül a "hogyan mentsem xml-be?" problémája...
azt szeretnem kerdezni, hogy hogyan lehet a tranzakcios logot egy adatbazisban kiuriteni? Masfel gigas, es tok foloslegesen ezzel hurcolassuk magunkkal a dumpokat.
A file-t torolni nem lehet, szoval valahogy uriteni kellene.
Hogy lehetne?
Koszi,
B.
Már kutakodtam, csak nem veszek észre mindent (-: bár az alábbi linked tartalmat ODBC doksiból már olvastam. Most pl. ott akadtam el, hogy az eljárásban kiadott select eredményét nem látom sehogy, pedig (egyetlen select esetén) ugyanúgy kéne látnom, mintha közvetlenül ODBC-ből hívnám a selectet. Na mind1, még kísérletezem.
Ha ez így van, akkor neked csak annyit kell tenned, hogy a 'csak' nevű tárolt eljárásodban commit-olsz egyet a begin tran helyett.. mert ugye az lezárja az előző tranzakciót, a manual commit mód miatt meg indít egy újat.
Pont ezt csináltam. A @@trancount kiírás nem jó, mert ODBC-ből futtatva semmi kiírást nem látok. Az igazi az lenne, ha az ODBC önműködő tranzakciókezdését ki lehetne kapcsolni, mert én csinálnék olyan tranzakciót, ami mondjuk két SQL eljárásból állna.
A programod autocommit_off állapotban működik, tehát ez a manual commit mód.
Ez pedig azt jelenti, hogy automatikusan indít egy tranzakciót, és te ezeket le tudod zárni egy SQLEndTran-nal. Ezután ő megint indít egy újat.
Ha ez így van, akkor neked csak annyit kell tenned, hogy a 'csak' nevű tárolt eljárásodban commit-olsz egyet a begin tran helyett.. mert ugye az lezárja az előző tranzakciót, a manual commit mód miatt meg indít egy újat.
én teleírogatnám a tárolt eljárásodat @@TRANCOUNT kiírogatásokkal. Konkrétan azt kell nézni, hogy igaz-e, hogy @@TRANCOUNT>0, amikor a tárolt eljárásod elindul. Ha igen, akkor begin trans helyett commit trans kellene. ekkor megint megnézném a @@TRANCOUNT értékét, hogy nyitott-e újat magától. ha igen, akkor a tárolt eljárás végén marad az commit tran.
amúgy lehet a tranzakciókat egymásba ágyazni, kérdés, hogy akarsz-e a tárolt eljáráson kívüli kódrészt tranzakciózni. gondolok itt pl egy ilyenre
select ...
...
begin trans
exec csak
insert into ...
commit trans
...
select ...
ha nem, akkor ld. 2. bekezdésem. ha igen, akkor paraméterben add át a tárolt eljárásodnak, hogy foglalkozzon-e a tranzakciókkal. ha kívül nyitsz, akkor belül ne
nyisson újat..
a simple model okés, de akkor legyenek rendszeres complete backupok! ekkor a sikeres backup után törli a tranzakciós logot.
ha mégsem, akkor
dbcc shrinkdatabase(dbname)
Igaz, hogy ez egy másik hétfő, de mostanra jutottam az eljárásokig. A gond az volt, hogy én indítottam tranzakciót, és mivel az ODBC még autocommit_off mellett is indít tranzakciót, kettő volt nyitva. Ezt pedig amennyire látom, nem lehet megszüntetni, mert én nem indíthatok, ezért belépéskor és kézi SQLEndTran után mindig nyit egyet. Amúgy megnéztem, alapból read_committed van beállítva. Mennyire lehet tranzakciókat egymásba ágyazni?
Enterpise Manager-ben elmész egészen az adatbázisig. Ott jobbgomb, tukajdonságok, Options fül. Van ott egy olyan, hogy Model. 3 értéket vehet fel, Simple, Full, Bulk logged. Szerintem a cégednél ez Full-on van, amikor minden megmozdulást naplóz. Állitsd át Simple-re, akkor kissebb lesz a log mérete. Legalábbis nálunk ez megoldás volt a problémára.
Sziasztok.
Vagy egy olyan dolog, hogy megrendelonknel fut a kis progink. Az adatbazis datafile-ja kb 250MB. Viszont a logfile hozza nagyobb mint 1GB. Nalam itthon ez nem ilyen, a logfile kisebb mint maga a datafile. Ez a megrendelonel fennallo eset azert ciki mert a backup file-ok, amiket mi is megkapunk (megkapnank...) az 1GB-os logfile miatt nagyon nagyok, meg tomoritve. Mi lehet elallitva, vagy egyaltalan mit kell allitani, hogy a logfile ne nojjon ilyen nagyon?
Volt nehany szerver es adatbazis koltoztetes naluk, azota ilyen nagy.
Valaszokat megkoszonom.
B.
jah :) egyszer már én is állítottam be egy ügyfélhez 2000-es szerverről backupolt adatbázissal, hogy íme itt az adatbázis, csak restore-olni kell. :) ott meg csak 7.0-ás volt. az persze egyszerűbb eset volt, legalább a programot nem kellett átírni.
Nem tért vissza senki. Én voltam hülye, elfelejtetem, hogy nekik csak 7-esük van, és SQL2000-ben írtam a programot. Hála neked, már tulajdonképpen működik is, csak még valami VB objektum .update metódusa száll el a triggerektől, és az se mindig, és az már az SQL200-rel is elszállt.
Én induláskor elég hamar kiadok egy
SQLSetConnectAttr(hdbc,SQL_ATTR_AUTOCOMMIT,SQL_AUTOCOMMIT_OFF,NULL);
hívást. Ez az ODBC bűne lehet. Hogy viszonyulhat ez az IMPLICIT TRANSACTION-hoz?
Köszi szépen, ez nagy segítség lesz hétfőn. Majd írom, hogy mire jutottam.
Az itt leírtak alapján én kipróbálnék a program végén (vagy inkább az elején) egy SET IMPLICIT TRANSACTION OFF-ot
Transactions that are automatically opened as the result of this setting being ON must be explicitly committed or rolled back by the user at the end of the transaction.
Szóval ha jól értem, akkor ON állás esetén ő nyit automatikusan tranzakciót, de neked kell lezárni. Viszont elméletileg csak akkor nyit az INSERT-re új tranzakciót, ha még nincs nyitott tranzakció ehhez a connection-hoz.
When a connection is in implicit transaction mode and the connection is not currently in a transaction, executing any of the following statements starts a transaction:
Ez pedig nem áll, hiszen épp az INSERT előtt nyitsz.
Én beszúrnék egy két @@TRANCOUNT változó lekérdezgetést. Ez megadja, hogy mennyi nyitott tranzakció van, illetve megnézném OFF állapotba kapcsolt implicit tranzakciókkal. Ha úgy megy, akkor meg az ODBC vagy program connection beállításaiban megkeresném azt a kapcsolót, ami miatt ő úgy gondolja, hogy jó neked ez az impicit tranzakciózás.
vagy megpróbálnám kézileg SET TRANSACTION ISOLATION LEVEL READ COMMITTED-et beállítani (a tárolt eljárásban a begin trans előtt), hátha nem az a default tranzakció mód. mert az, hogy lockolja a táblát, azt csak lezáratlan tranzakció hatására tudom elképzelni.
Á, tényleg, nem tudom, miért is gondoltam, hogy a FOR trigger BEFORE-t jelent (talán az átkozott germán múveltségem...). Az INSTEAD OF-ra pedig tényleg az eredeti értékek visszaírása tűnik a legjobb ötletnek.
SQL:BatchStarting 2004-10-01 14:15:27.263 select 504,c.name,c.description,c.definition from master.dbo.syscharsets c where c.id = convert(tinyint, databasepropertyex ( db_name() , 'sqlcharset'))
(van stmtstarting, stmtcompleted és batchcompleted azonossal)
SQL:BatchStarting 2004-10-01 14:15:39.467 set implicit_transactions on
(itt is)
RPC:Starting 2004-10-01 14:15:39.467 exec csak
SP:Starting 2004-10-01 14:15:39.467 exec csak
SP:StmtStarting 2004-10-01 14:15:39.467 -- csak
begin tran
SQLTransaction 2004-10-01 14:15:39.467
SP:StmtCompleted 2004-10-01 14:15:39.467 0 2 -- csak
begin tran
SP:StmtStarting 2004-10-01 14:15:39.467 -- csak
insert into tortenes (ido,ezred,fajta) values ('2004-12-23 12:12:12',2,3)
SP:StmtCompleted 2004-10-01 14:15:39.467 0 90 -- csak
insert into tortenes (ido,ezred,fajta) values ('2004-12-23 12:12:12',2,3)
SP:StmtStarting 2004-10-01 14:15:39.483 -- csak
commit tran
SP:StmtCompleted 2004-10-01 14:15:39.483 0 4 -- csak
commit tran
SP:Completed 2004-10-01 14:15:39.467 exec csak
RPC:Completed 2004-10-01 14:15:39.467 0 165 exec csak
és tartja a táblát. Megállítottam a felvételt, és kiléptem a programból. Nekem az az implicit transactions on nagyon gyanús.
most indítsd el a (hibásan működdő) programodat és nézd meg, hogy milyen utasításokat küld a servernek. lehetőleg a program indításakor már menjen a profiler trace, mert valszeg az elején küldi el a beállításokat.
az eseményeket tudod filterezni (ha nem tud a trace, akkor properties->filters), érdemes mondjuk ApplicationName-re vagy spid-re, ha sokan használják egyszerre a servert.
Miután megnéztem, tudom mi az isolation level, csak az értékét nem adta vissza a dög (azzal, amit írtam). Na, belőttem a Profilert. Beadtam szinte minden eseményt, ami nem mondjuk auditos, tehát köze lehet a bajhoz. Beindítottam, a már futó Query analizerbe beírtam azt, hogy
use enyem
go
exec csak
go
(az, hogy go fölösleges, nem érdekelt, így jutott eszembe) majd leállítottam (később megnéztem, sikerült). Az eredmény ezernyi esemény, aminek 90 %-a lockos. Valószínűleg finomabb beállítás kell. Mit érdemes?
az isolation level a tranzakciók elkülönítésének a szintje. ha serializable, akkor a tranzakciókat sorba állítja, és egy tranzakció csak akkor tud elindulni, ha az előző, ami ugyanarra az objektumra vonatkozik, már végzett, addig csak vár. a
paranccsal állíthatod be. mondjuk, ha nem állítottad át, akkor az alap valószínűleg read committed, az meg nem okoz blokkolást.
Hogy miért van különbség? Biztos valami mást kódot, alap beállításokat is elküld a fejlesztőkörnyezet a szervernek, nem csak a te kódodat.
Indítsd el a Profilert és nézd meg, mi a különbség a két verzió által küldött parancsok közt. (Ha még nem használtad, néhány szóban leírom, de feleslegesen nem terhelem a topikot. :)
Igen, mert a többit kiirtottam. Meg akartam tartani a körítést, hátha az is befolyásol.
Nem tudom, mi az isolation level, mert a
dbcc useroptions
(M$ SQL Server 2000 doksi javasolta erre) nem írja ki. Miért lockolná commit után? Vagy azt kézzel kell fölszabadítani? Tényleg csak akkor férek hozzá a táblához, ha kiléptem a programból.
Miért van az, hogy Query Analizerből hívva az eljárást, vagy ODBC-ből mondatonként végrehajtva ugyanazt működik?
