Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Sidan Konvertering i dialogrutan Projektinställningar innehåller inställningar som anpassar hur SSMA konverterar Oracle-syntax till SQL Server-syntax.
Fönstret Konvertering är tillgängligt i dialogrutorna Projektinställningar och Standardprojektinställningar.
Om du vill ange inställningar för alla SSMA-projekt går du till menyn Verktyg och klickar på Standardprojektinställningar, väljer projekttyp för migrering som måste visas eller ändras från listrutan Migreringsmålversion , klickar sedan på Allmänt längst ned i den vänstra rutan och klickar sedan på Konvertering.
Om du vill ange inställningar för det aktuella projektet klickar du på Projektinställningar på verktygsmenyn och sedan på Allmänt längst ned i det vänstra fönstret och klickar sedan på Konvertering.
Inbyggda funktioner och medföljande paket
| Begrepp | Definition |
|---|---|
| Konvertera funktionen COUNT till COUNT_BIG | Om dina COUNT funktioner sannolikt returnerar värden som är större än 2 147 483 647, vilket är 231–1, bör du konvertera funktionerna till COUNT_BIG.Om du väljer Ja konverterar SSMA alla användningsområden COUNT för till COUNT_BIG.Om du väljer Nej förblir funktionerna som COUNT. SQL Server returnerar ett fel om funktionen returnerar ett värde som är större än 231–1.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standard/fullständigt läge: Ja optimistiskt läge: Nej |
| Konvertera SUBSTR-funktionsanrop till SUBSTRING-funktionsanrop | SSMA kan konvertera Oracle-funktionsanrop SUBSTR till SQL Server-funktionsanrop substring , beroende på antalet parametrar. Om SSMA inte kan konvertera ett SUBSTR funktionsanrop, eller om antalet parametrar inte stöds, konverterar SSMA funktionsanropet SUBSTR till ett anpassat SSMA-funktionsanrop.Om du väljer Ja konverterar SUBSTR SSMA funktionsanrop som använder tre parametrar till SQL Server substring. Andra SUBSTR funktioner konverteras för att anropa den anpassade SSMA-funktionen.Om du väljer Nej konverterar SSMA funktionsanropet SUBSTR till ett anpassat SSMA-funktionsanrop.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Ja fullständigt läge: Nej |
| Konvertera funktionsanrop för TO_CHAR(datum, format) | SSMA kan konvertera Oracle TO_CHAR(date, format) till procedurer från ssma_oracle schemat.Om du väljer Använda TO_CHAR_DATE-funktionen, konverterar SSMA TO_CHAR(date, format)-funktionen till TO_CHAR_DATE-funktionen med hjälp av engelska språket för konvertering.Om du väljer Använda TO_CHAR_DATE_LS funktion (NLS-hantering), konverterar SSMA TO_CHAR(date, format) till TO_CHAR_DATE_LS-funktionen med hjälp av sessionsspråket för konverteringNär du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: med funktionen TO_CHAR_DATE Fullständig läge: Använder funktionen TO_CHAR_DATE_LS (med hänsyn till NLS) |
| Generera fel för DBMS_SQL.PARSE | Om du väljer Fel genererar SSMA fel vid konverteringen DBMS_SQL.PARSE.Om du väljer Varning genererar SSMA varning vid konverteringen DBMS_SQL.PARSE.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standard/optimistiskt/fullständigt läge: fel |
| Använda ISNULL i CONCAT-funktionsanrop |
ISNULL -instruktionen används i CONCAT funktionsanrop för att emulera Oracle-beteende. Följande alternativ finns för den här inställningen:JA NEJ När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Nej fullständigt läge: Ja |
| Använda ISNULL i REPLACE-funktionsanrop |
ISNULL -instruktionen används i REPLACE funktionsanrop för att emulera Oracle-beteende. Följande alternativ finns för den här inställningen:JA NEJ När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Nej fullständigt läge: Ja |
| Använd intern konvertera-funktion när det är möjligt | Om du väljer Ja, konverterar SSMA TO_CHAR(date, format) till den inbyggda konverteringsfunktionen när det är möjligt.Om du väljer Nej konverterar TO_CHAR(date, format) SSMA till TO_CHAR_DATE eller TO_CHAR_DATE_LS (det definieras av alternativen Konvertera TO_CHAR(datum, format ).När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Ja fullständigt läge: Nej |
Konverteringsmeddelanden
| Begrepp | Definition |
|---|---|
| Generera meddelanden om problem | Anger om SSMA genererar informationsmeddelanden under konverteringen, visar dem i fönstret Utdata och lägger till dem i den konverterade koden. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Nej fullständigt läge: Nej |
Diverse alternativ
| Begrepp | Definition |
|---|---|
| Omvandla ROWNUM-uttryck som heltal | När SSMA konverterar ROWNUM uttryck konverteras uttrycket till en TOP sats följt av uttrycket. Följande exempel visar ROWNUM i ett Oracle-uttalande DELETE :DELETE FROM Table1WHERE ROWNUM < expression and Field1 >= 2I följande exempel visas det resulterande Transact-SQL: DELETE TOP (expression-1)FROM Table1WHERE Field1>=2TOP kräver att TOP satsuttrycket utvärderas till ett heltal. Om heltalet är negativt kommer ett fel att uppstå.Om du väljer Jaomvandlar SSMA uttrycket till ett heltal. Om du väljer Nej markerar SSMA alla icke-heltalsuttryck som ett fel i den konverterade koden. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standard/fullständigt läge: Nej optimistiskt läge: Ja |
| Standardschemamappning | Den här inställningen anger hur Oracle-scheman mappas till SQL Server-scheman. Det finns två alternativ i den här inställningen: Schema till databas: I det här läget mappas Oracle-schemat sch1 som standard till dbo SQL Server-schemat i SQL Server-databasen sch1.Schema för schema: I det här läget mappas Oracle-schemat sch1 som standard till sch1 SQL Server-schemat i sql server-standarddatabasen som tillhandahålls i anslutningsdialogrutan.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standard/optimistiskt/fullständigt läge: schema till databas |
| Emulera Oracles null-värdesbeteende i ORDER BY-uttrycken |
NULL värdena sorteras på olika sätt i SQL Server och Oracle:I SQL Server är NULL värden de lägsta värdena i en ordnad lista. I en stigande lista NULL visas värden först.I Oracle NULL är värdena de högsta värdena i en ordnad lista. Som standard visas NULL värden sist i en stigande ordningslista.Oracle har NULLS FIRST och NULLS LAST -satser, vilket gör att du kan ändra hur Oracle beställer NULLs.SSMA kan emulera Oracle-beteende ORDER BY genom att kontrollera NULL för värden. Den sorterar först efter NULL-värden i den angivna ordningen och sedan efter andra värden.Om du väljer Ja konverterar SSMA Oracle-instruktionen på ett sätt som emulerar Oracle-beteendet ORDER BY .Om du väljer Nej ignorerar SSMA Oracle-regler och genererar ett felmeddelande när det påträffar satserna NULLS FIRST och NULLS LAST .När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Nej fullständigt läge: Ja |
| Emulera undantag för radantal i SELECT | Om en SELECT instruktion med en INTO-sats inte returnerar några rader genererar Oracle ett NO_DATA_FOUND undantag. Om satsen returnerar två eller flera rader utlöses undantaget TOO_MANY_ROWS. Den konverterade instruktionen i SQL Server genererar inget undantag om radantalet skiljer sig från ett.Om du väljer Ja lägger SSMA till anrop till en särskild db_error_exact_one_row_check procedur efter varje SELECT instruktion. Den här proceduren emulerar undantagen NO_DATA_FOUND och TOO_MANY_ROWS . Detta är standardvärdet och tillåter återskapande av Oracle-beteende så nära som möjligt. Du bör alltid välja Ja om källkoden har undantagshanterare som bearbetar dessa fel. Observera att om -instruktionen SELECT inträffar i en användardefinierad funktion konverteras den här modulen till en lagrad procedur, eftersom körning av lagrade procedurer och höjning av undantag inte är kompatibelt med SQL Server-funktionskontexten.Om du väljer Nej genereras inga undantag. Det kan vara användbart när SSMA konverterar en användardefinierad funktion och du vill att den ska förbli en funktion i SQL Server När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Aktivera Fix Advisor | När det är aktiverat försöker SSMA lära sig av de ändringar du gör i T-SQL-målkoden och föreslår potentiella kodkorrigeringar på andra platser, där liknande mönster kan tillämpas. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Generera kolumnalias för konstanta uttryck | Om uttrycket i SELECT listan saknar ett alias kan SSMA generera konstant alias (till exempel expr1, expr2osv.) eller använda själva uttrycket som ett alias. Eftersom uttryck kan bli ganska långa och kolumnnamnslängden är begränsad är det säkrare att använda konstant basnamn för sådana alias. Även om det är ett säkrare alternativ är det ibland inte möjligt, eftersom det kan finnas externa beroenden för den resulterande datamängden. I dessa fall kanske du vill namnge kolumner enligt deras värdeuttryck, ungefär som Oracles beteende.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard-/optimistiskt läge: Ja fullständigt läge: Nej |
| Utelämna utökade egenskaper | När det är aktiverat lägger SSMA inte till utökade egenskaper till de objekt som skapas i måldatabasen. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Nej |
| Översätta felkoder | När aktiverat översätts felnumret på mål-SQL Server-sidan till en Oracle-felkod om mappningen hittas. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standard/fullständigt läge: Ja optimistiskt läge: Nej |
| Använd fullständig typspecifikation för typreferenser | När det är aktiverat respekterar SSMA fullständig typspecifikation (inklusive skalning och precision) för rutinparametrar och returvärden. Oracle tillåter inte datatypsargument för rutinparametrar, men det finns fall där de implicit kan härledas, till exempel när %TYPE och %ROWTYPE attribut används. I sådana fall kan SSMA använda fullständig typspecifikation (inklusive precision och skalning) när du konverterar den till SQL Server.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Ja fullständigt läge: Nej |
| Använda ISNULL i strängsammanfogning | Oracle och SQL Server returnerar olika resultat när strängsammanfogningar innehåller NULL värden. Oracle behandlar värdet NULL som en tom teckenuppsättning. SQL Server returnerar NULL.Om du väljer Ja ersätter SSMA Oracle-sammanfogningstecknet (||) med SQL Server-sammanlänkningstecknet (+). SSMA kontrollerar också uttrycken på båda sidor av konkateneringen för NULL-värden.Om du väljer Nejersätter SSMA sammanfogningstecken, men söker inte efter NULL värden.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
Objektkonvertering
| Begrepp | Definition |
|---|---|
| Konvertera sekundärnycklar med SET NULL-referensåtgärd för kolumn som inte är NULL | Oracle tillåter att begränsningar för sekundärnyckel skapas, där en SET NULL åtgärd inte kan utföras eftersom NULL:er inte tillåts i den refererade kolumnen. SQL Server tillåter inte sådan sekundärnyckelkonfiguration.Om du väljer Ja genererar SSMA referensåtgärder som i Oracle, men du måste göra manuella ändringar innan du läser in begränsningen till SQL Server. Du kan till exempel välja NO ACTION i stället för SET NULL.Om du väljer Nej markeras villkoret som ett fel. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Nej |
| Konvertera undertyper | SSMA kan konvertera PL/SQL-undertyper på två sätt: Om du väljer Ja skapar SSMA en användardefinierad SQL Server-typ från en undertyp och använder den för varje variabel i den här undertypen. Om du väljer Nej ersätter SSMA alla källdeklarationer av undertypen med den underliggande typen och konverterar resultatet som vanligt. I det här fallet skapas inga ytterligare typer i SQL Server När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Nej |
| Konvertera synonymer | Synonymer för följande Oracle-objekt kan migreras till SQL Server: Tabeller och objekttabeller Vyer och objektvyer Lagrade procedurer och funktioner Materialiserade vyer Synonymer för följande Oracle-objekt kan ersättas med direkta referenser till objekten: Sekvenser Paket Java-klassschemaobjekt Användardefinierade objekttyper Andra synonymer kan inte migreras. SSMA genererar felmeddelanden för synonymen och alla referenser som använder synonymen. Om du väljer Ja skapar SSMA SQL Server-synonymer och direkta objektreferenser enligt föregående listor. Om du väljer Nej skapar SSMA direkta objektreferenser för alla synonymer som anges här. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Konvertering av lokala moduler | Definierar typen av konvertering för Oracle-kapslat underprogram (deklarerat i fristående lagrad procedur eller funktion). Om du väljer Infoga ersätts de kapslade underprogramanropen med dess brödtext. Om du väljer Lagrade procedurer konverteras kapslat underprogram till en lagrad SQL Server-procedur och dess anrop ersätts i det här proceduranropet. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/optimistiskt/fullständigt läge: inline |
Registerkonvertering
| Begrepp | Definition |
|---|---|
| Konvertera posten till en lista över separerade variabler | SSMA kan konvertera Oracle-poster till separata variabler och till XML-variabler med specifik struktur. Om du väljer Ja, konverterar SSMA posten till en lista med separata variabler när det är möjligt. Om du väljer Nejkonverterar SSMA posten till XML-variabler med specifik struktur. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Använd SELECT...FÖR XML vid konvertering av SELECT...INTO för rekordvariabel | Anger huruvida en XML-resultatuppsättning ska genereras när du väljer in i en postvariabel. Om du väljer Jareturnerar SELECT-instruktionen XML. Om du väljer Ingenreturnerar SELECT-instruktionen en resultatuppsättning. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Nej |
Omvandling av RETURNING-argument
| Begrepp | Definition |
|---|---|
| Konvertera RETURNING-sats i DELETE-instruktionen till OUTPUT | Oracle tillhandahåller en RETURNING sats som ett sätt att omedelbart hämta borttagna värden. SQL Server tillhandahåller den funktionen med OUTPUT-satsen.Om du väljer Ja kommer SSMA att konvertera klausuler i RETURNING-satser till DELETE-klausuler. Eftersom utlösare i en tabell kan ändra värden kan det returnerade värdet vara annorlunda i SQL Server än i Oracle.Om du väljer Nej genererar SSMA en SELECT instruktion före DELETE instruktioner för att hämta returnerade värden.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Konvertera RETURNING-uttryck i INSERT-uttryck till OUTPUT | Oracle tillhandahåller en RETURNING sats som ett sätt att omedelbart hämta infogade värden. SQL Server tillhandahåller den funktionen med OUTPUT-satsen.Om du väljer Ja konverterar SSMA en RETURNING sats i en INSERT -instruktion till OUTPUT. Eftersom utlösare i en tabell kan ändra värden kan det returnerade värdet vara annorlunda i SQL Server än i Oracle.Om du väljer Nej emulerar SSMA Oracle-funktioner genom att infoga och sedan välja värden från en referenstabell. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Konvertera RETURNING-sats i UPDATE-instruktionen till OUTPUT | Oracle tillhandahåller en RETURNING sats som ett sätt att omedelbart hämta uppdaterade värden. SQL Server tillhandahåller den funktionen med OUTPUT-satsen.Om du väljer Ja kommer SSMA att konvertera klausuler i RETURNING-satser till UPDATE-klausuler. Eftersom utlösare i en tabell kan ändra värden kan det returnerade värdet vara annorlunda i SQL Server än i Oracle.Om du väljer Nej genererar SSMA SELECT-instruktioner efter UPDATE -instruktioner för att hämta returnerade värden.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
ROWID-generering
| Begrepp | Definition |
|---|---|
| Generera ROWID-kolumn | När SSMA skapar tabeller i SQL Server kan det skapa en ROWID-kolumn. När data migreras hämtar varje rad ett nytt UNIQUEIDENTIFIER värde som genereras av newid() funktionen.Om du väljer Ja ROWID skapas kolumnen i alla tabeller och SQL Server genererar GUID som dina infogade värden. Välj alltid Ja om du planerar att använda SSMA-testaren.Om du väljer Nej läggs inte ROWID-kolumner till i tabeller. Lägg till ROWID-kolumn för tabeller med trigger och lägg till ROWID för tabeller som innehåller trigger.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Lägg till ROWID-kolumn för tabeller med utlösare fullständigt läge: Ja |
| Generera unikt index i ROWID-kolumnen | Anger om SSMA genererar en unik indexkolumn i den ROWID genererade kolumnen eller inte. Om alternativet är inställt på "JA" genereras ett unikt index och om det är inställt på "NEJ" genereras inte unikt index i ROWID kolumnen.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
Sekvens- och identitetskonvertering
| Begrepp | Definition |
|---|---|
| Konvertera identitet till | Oracle tillhandahåller flera konfigurationsalternativ för identitetskolumner. Vissa av dessa alternativ stöds inte av identitetsfunktionen i SQL Server. En metod för att bevara dessa alternativ är att konvertera identitet som en sekvens. Om du väljer Sekvens konverteras inte längre Oracle-identitetskolumner till SQL-identitetskolumner. I stället skapas en sekvens och används för att generera standardvärden för kolumnen. Om du väljer Identitet konverteras Oracle-identitetskolumner till SQL-identitetskolumner. Alternativ som inte stöds konverteras inte. Om du väljer Bästa passform avgör SSMA den bästa konverteringsmetoden (identitet eller sekvens) beroende på konfigurationen av Oracle-identitetskolumnen. |
| Konvertera sekvensgenerator | I Oracle kan du använda en sekvens för att generera unika identifierare. SSMA kan konvertera sekvenser till följande. Använda SQL Server-sekvensgenerator. Använda SSMA-sekvensgenerator. Använda kolumnidentitet. Standardalternativet är att använda SQL Server-sekvensgenerator. SQL Server stöder dock inte hämtning av aktuellt sekvensvärde (till exempel för Oracle-sekvensmetoden CURRVAL ). Mer information om hur du migrerar Oracle-sekvensmetod CURRVAL finns på SSMA-teamets bloggwebbplats.SSMA ger också ett alternativ för att konvertera Oracle-sekvens till SSMA-sekvensemulator. Det här är standardalternativet när du konverterar till SQL Server före 2012 Slutligen kan du också konvertera sekvens som tilldelats till en kolumn i tabellen till SQL Server-identitetsvärden. Du måste ange mappningen mellan sekvenserna till en identitetskolumn på fliken Oracle-tabell |
| Konvertera CURRVAL utanför utlösare | Visas bara när konvertera sekvensgeneratorn är inställd på Använda kolumnidentitet. Eftersom Oracle-sekvenser är objekt som är separata från tabeller använder många tabeller som använder sekvenser en utlösare för att generera och infoga ett nytt sekvensvärde. SSMA kommenterar ut dessa instruktioner eller markerar dem som fel när kommentaren skulle generera fel. Om du väljer Ja markerar SSMA alla referenser till externa utlösare i den konverterade sekvensen CURRVAL med en varning.Om du väljer Nej markerar SSMA alla referenser till externa utlösare i den konverterade sekvensen CURRVAL med ett fel. |
Omvandling av påståenden
| Begrepp | Definition |
|---|---|
| Konvertering av MERGE-instruktion | Om du väljer Using INSERT, UPDATE, DELETE-instruktion konverterar SSMA -instruktionen MERGE till INSERT, UPDATE, DELETE -instruktioner.Om du väljer Använda MERGE-instruktion konverterar SSMA -instruktionen MERGE till MERGE -instruktion i SQL Server.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Default/Optimistic/Full-läge: Använda MERGE-instruktion |
| Konvertera anrop till underprogram som använder standardargument | SQL Server-funktioner stöder inte utelämnande av parametrar i funktionsanropet. Sql Server-funktioner och -procedurer stöder inte heller uttryck som standardparametervärden. Om du väljer Ja och ett funktionsanrop utelämnar parametrar infogar SSMA nyckelordsstandarden i funktionen och anropar i rätt position. Sedan markeras samtalet med en varning. Om du väljer Nej markerar SSMA funktionsanropen som fel. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Konvertera FORALL-instruktion till WHILE-instruktion | Definierar hur SSMA ska behandla FORALL loopar på PL/SQL-samlingselement.Om du väljer Ja skapar SSMA en WHILE loop där samlingselement hämtas en i taget.Om du väljer Nej genererar SSMA en raduppsättning från samlingen med hjälp av nodes() metoden och använder den som en enda tabell. Detta är mer effektivt, men gör utdatakoden mindre läsbar.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: standardläge/optimistiskt läge: Nej fullständigt läge: Ja |
| Konvertera funktionsanrop till proceduranrop | Vissa Oracle-funktioner definieras som autonoma transaktioner eller innehåller instruktioner som inte skulle vara giltiga i SQL Server. I dessa fall skapar SSMA en procedur och en funktion som är ett omslag för proceduren. Den konverterade funktionen anropar implementeringsproceduren. SSMA kan konvertera anrop till omslutningsfunktionen så att de blir anrop till proceduren. Detta skapar mer läsbar kod och kan förbättra prestanda. Kontexten tillåter det dock inte alltid. Du kan till exempel inte ersätta ett funktionsanrop i SELECT listan med ett proceduranrop. SSMA har några alternativ för att täcka vanliga fall:Om du väljer Alwaysförsöker SSMA konvertera omslutningsfunktionsanrop till proceduranrop. Om den aktuella kontexten inte tillåter den här konverteringen genereras ett felmeddelande. På så sätt finns inga funktionsanrop kvar i den genererade koden. Om du väljer När det är möjligtgör SSMA anrop till procedurer endast om funktionen har utdataparametrar. När flytten inte är möjlig tas parameterns utdataattribut bort. I alla andra fall lämnar SSMA funktionsanrop. Om du väljer Aldrig lämnar SSMA alla funktionsanrop som funktionsanrop. Ibland kan det här valet vara oacceptabelt på grund av prestandaskäl. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: När det är möjligt |
| Konvertera LOCK TABLE-instruktioner | SSMA kan konvertera många LOCK TABLE instruktioner till tabelltips. SSMA kan inte konvertera några LOCK TABLE instruktioner som innehåller PARTITION, SUBPARTITION, @dblinkoch NOWAIT -satser, och kommer att markera sådana instruktioner med konverteringsfelmeddelanden.Om du väljer Ja, konverterar SSMA de stödta instruktionerna LOCK TABLE till tabelltips.Om du väljer Nej markerar SSMA alla LOCK TABLE instruktioner med konverteringsfelmeddelanden.I följande tabell visas hur SSMA konverterar Oracle-låslägen: Oracle-låsläge ROW SHAREROW EXCLUSIVESHARE UPDATE = ROW SHARESHARESHAREEXCLUSIVETabelltips för SQL Server ROWLOCK, HOLDLOCKROWLOCK, XLOCK, HOLDLOCKROWLOCK, HOLDLOCKTABLOCK, HOLDLOCKTABLOCK, XLOCK, HOLDLOCKTABLOCKX, HOLDLOCKNär du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Konvertera OPEN-FOR-instruktioner för REF CURSOR OUT-parametrar | I Oracle kan -instruktionen OPEN .. FOR användas för att returnera en resultatuppsättning till ett underprograms OUT parameter av typen REF CURSOR. I SQL Server returnerar lagrade procedurer resultatet av SELECT -instruktioner direkt.SSMA kan konvertera många OPEN .. FOR instruktioner till SELECT -instruktioner.Om du väljer Ja konverterar SSMA -instruktionen OPEN .. FOR till en SELECT -instruktion som returnerar resultatuppsättningen till klienten.Om du väljer Nej genererar SSMA ett felmeddelande i den konverterade koden och i fönstret Utdata. När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |
| Konvertera transaktionsbearbetningsuttalanden | SSMA kan konvertera Oracle-transaktionsbearbetningssatser: Om du väljer Ja konverterar SSMA Oracle-transaktionsbearbetningssatser till SQL Server-instruktioner. Om du väljer Nejmarkerar SSMA transaktionsbearbetningsinstruktionerna som konverteringsfel. Notera: Oracle öppnar transaktioner implicit. Om du vill emulera det här beteendet på SQL Server måste du lägga till BEGIN TRANSACTION instruktioner manuellt där du vill att dina transaktioner ska starta. Du kan också köra SET IMPLICIT_TRANSACTIONS ON kommandot i början av sessionen. SSMA lägger till SET IMPLICIT_TRANSACTIONS ON automatiskt när du konverterar subrutinerna med autonoma transaktioner.När du väljer ett konverteringsläge i rutan läge tillämpar SSMA följande inställning: Standard/Optimistiskt/Fullständigt läge: Ja |