kopiering af tabel til ny

I Enterprise Manager kan du godt højreklikke på en tabel, gå ind og tilføje et nyt felt, eventuelt ændre felter, og derefter gemme tabellen igen. SQL Server vil da selv sørge for eventuelt at kopiere data over i en ny tabel og rename denne tilbage til det oprindelige navn.

kan jeg ikke når det drejer sig om identity colums med not null værdi

INSERT INTO nytabel(felt1,felt2,...,feltx) SELECT * FROM gltabel

hvor listen af felter er felterne som er i den gamle tabel

kan jeg kun hvis felterne er de samme og problemet er netop at der skal være et ekstra id-felt i den nye, som tilsyneladende er nødvendigt at sætte på først. Kunne jeg sætte det på bagefter, var det ikke noget problem, men det har jeg ikke kunnet endnu.

Øh.

Du opretter en flunkende ny tabel. Med de felter du skal bruge.

Så flytter du data over fra den gamle tabel med de felter som matcher.

Og SQL Server genererer selv værdier for den tilføjede identity kolonne.

når jeg prøver får jeg meddelelsen: Microsoft ODBC SQL Server Driver SQL Server Cannot insert the value Null into Column 'id', Table 'PLVKTSYS.dbo.Hovedtabel'; Column does not allows nulls. INSERT fails.

Er det ikke en IDENTITY kolonne ?

det er en uniqueidentifier og en identifier kan ikke være 0. kom lige til at tænke på at jeg vil prøve om jeg kan oprette den første plads manuelt.

kan jeg heller ikke, vil den ikke lige tage heller.

andre ideer?

jeg er nået frem til at jeg måske kan bruge ALTER TABLE på den gamle tabel, men mangler den rigtige formulering.
Tabellen hovedtabel1 har nu primary key vkt_nr og skal have indsat ny column id som primary key.
Jeg har sætningen:ALTER TABLE hovedtabel1 DROP PRIMARY KEY ON hovedtabel1.vkt_nr ALTER TABLE hovedtabel1 ADD COLUMN [id] AS PRIMARY KEY; men får meddelsen Incorrect syntax near the keyword 'PRIMARY'.
nogen ideer?

jeg har i entreprise manager forsøgt at gøre som vejledningen siger jeg skal (SQL Server books online), men bliver afvist, må ikke gøre det de skriver jeg skal for at ændre det derfra.

Beklager der er åbenbart ikke flere SQL eksperter her. prøver hos sqlservercentral.com, de har vist lidt mere styr over det.

Nu prøver jeg:

1: Åbn Enterprise manager
2: Højreklik på den og vælg Kopier
3: Gå herind og "Sæt ind", så vil du kunne sende os et createscript for tabellen

Jeg tror næsten det vil opklare det ...

Jeg tror ikke at det er manglende viden hos svarerne her der er problemet snarere
at få en forståelig og korrekt beskrivelse af problemet.

jeg har en tom tabel 'hovedny' hvortil jeg skal have flyttet dataene fra 'hovedtabel1'. Jeg har på den tomme ændret definitionen af identifieren til int, istedet for unique identifier, det var ikke så svært, men problemet ligger i efter at have givet den nye tabel en ny id at få lov at indsætte de gamle data. Den gamle tabel havde en decimalværdi som identifier, hvilket ikke altid er en succes. jeg kan tilsyneladende ikke gøre det i entreprisemanager med de grafiske værktøjer. kan i sættte en sql query op der kan klare det? siider og bikser med det selv, men kan ikke få den rette sammensætning. Jeg har smidt et drop af den gamle tabel her, vidste ikke det var oprettelsesscriptet vi fik ved kopier, har godt nok undret mig over hvad den funktion kunne udrette

CREATE TABLE [Hovedtabel1] (
    [vkt_nr] [decimal](18, 1) NOT NULL ,
    [billede] [nvarchar] (255) COLLATE Danish_Norwegian_CI_AS NULL ,
    [fil1] [nvarchar] (255) COLLATE Danish_Norwegian_CI_AS NULL ,
    [fil2] [nvarchar] (255) COLLATE Danish_Norwegian_CI_AS NULL ,
    [gruppe] [int] NULL ,
    [undergruppe] [int] NULL ,
    [ops_overvkt] [int] NULL ,
    [ops_undervkt] [int] NULL ,
    [anvendelse] [int] NULL ,
    [bem_ t_ anv] [int] NULL ,
    [totallaengde] [int] NULL ,
    [delinger] [nvarchar] (110) COLLATE Danish_Norwegian_CI_AS NULL ,
    [bredde] [real] NULL ,
    [hoejde] [real] NULL ,
    [naeseRadius] [real] NULL ,
    [hornimm] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [vinkel] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [sporbredde] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [forsætn_prof_hoejde] [int] NULL ,
    [tegningshenvisning] [nvarchar] (255) COLLATE Danish_Norwegian_CI_AS NULL ,
    [placering] [int] NULL ,
    [reol] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [hylde] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [brugesaf] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [kunde] [int] NULL ,
    [leverandor] [int] NULL ,
    [rekvnr_ pris] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [bem_ t_ vaerk] [int] NULL ,
    [leveringsdato] [datetime] NULL ,
    [udgaaet] [bit] NOT NULL ,
    [udgaaetdato] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [ejer] [int] NULL ,
    [betalingsandel] [nvarchar] (50) COLLATE Danish_Norwegian_CI_AS NULL ,
    [aktiv] [int] NOT NULL ,
    [sidstekontrol] [int] NULL ,
    [notat] [int] NULL ,
    [upsize_ts] [binary] (8) NULL ,
    CONSTRAINT [PK_Hovedtabel1] PRIMARY KEY  CLUSTERED
    (
        [vkt_nr]
    )  ON [PRIMARY]
) ON [PRIMARY]
GO

OK, jeg kan se at du har en Primær nøgle på den gamle tabel, nemlig vkt_nr.

Er det sådan at du i stedet vil bruge det nye felt som nøgle? Du behøver ikke at lave en ny tabel.

Gør dette:

1: Åbn den gamle i design
2: Tilføj det nye felt, giv det et navn, angiv datatypen til int og sæt kryds i identity. Så skulle den selv ændre null til not null (Med mindre det er en gammel version vi taler om.
3: Tryk på Gem. Nu skulle den gerne fylde det nye felt ud med fortløbende numre.
4: Hvis det er det du vil, så marker vkt_nr, og klik nøglen væk, marker det nye felt og klik nøglen på. Tryk på gem

Jeg skulle mene at det vil gøre det

Din fejl var at du ikke angav det nye felt til at være identity

ufatteligt, det virkede tilsyneladende nu. mener ellers jeg har gjort det før uden at kunne - kan hænde det har været fordi jeg også har haft prøvet med id til uniqueidentifier? Hvad er en uniqueidentifier, når det ikke er et primærnøgle?

Uniqueidentifier er en datatype, og den har formen

{80520967-F21E-4721-8D8F-1483B3B02773}

Det er altså en meget stor tilfældig streng. Man bruger den som primær nøgle på tværs af adskilte systemer, fordi sandsynligheden for at den samme nøgle kommer ud flere gange er mikroskopisk, faktisk ikke til stede.

Det du sikkert troede var at det var noget tilsvarende det der i access hedder autonumerering, men det er det ikke. Autonumering i MSSQL foregår ved at du angiver et felt til at være identity. Der kan kun være et identityfelt i hver tabel.

Primær nøgle er et eller flere felter, i reglen et, som man bestemmer skal være unik for alle rækker i tabellen. Det er den man bruger når man henviser til en bestemt række. Du bestemmer selv hvilket felt det skal være, og det er dig der er ansvarlig for at der kommer unikke værdier i feltet, med mindre du bestemmer at MSSQL skal gøre det for dig. Det kan gøres ved at sige at feltet skal være identity (altså autonummering), eller timestamp, eller uniqueidentifier med default værdi NEWID().

og tak for point :o)

En af grundene til at det virkede nu er nok at du har trykket på gem flere gange under processen, som jeg angav.

jeg sprang endda ved et uheld det ene gem over og fik sat nøgle før gem. jeg kan ikke komme over at have bikset i flere dage med l... og så virker det pludseligt.
hvis jeg skal oprette en sikkerhedskopi af tabellen uden at fjerne indholdet (som jeg gør ved at eksportere) skulle jeg så ikke kunne gøre det ved at sige: insert into 'ny tabel' (liste af kolonner) select * from gl tabel? eller skal der bygges mere på? jeg kan ikke få den til at spise min syntaks.

Jo, det kan du godt, blot kan du normalt ikke inserte i et felt der er identity. MSSQL skal jo selv afgøre hvad værdien er.

Men du kan override det med:
SET IDENTITY_INSERT tabelnavn ON
INSERT INTO blabla
SET IDENTITY_INSERT tabelnavn OFF

Eller du kan blot vælge at identity kolonnen ikke skal være identity.

I begge tilfælde vil du alligevel få en fejl hvis du prøver at inserte rækker hvor ID'et allrede findes. Det er jo PRIMARY KEY, også i backup-tabellen, og derfor skal den være unik

Du kan gøre sådan (Antaget at den nye nøgle hedder ID):

SET IDENTITY_INSERT Hovedtabel1_backup ON

INSERT INTO Hovedtabel1_backup (col1, col2, ...) SELECT col1, col2, ... FROM Hovedtabel1 WHERE ID NOT IN (SELECT ID FROM Hovedtabel1_backup)

SET IDENTITY_INSERT Hovedtabel1_backup OFF

Den kan godt blive tung at køre efterhånden som der kommer mange data, så må du se dig om efter en smartere måde

col1, col2, ...

- Det betyder en liste over alle kolonner, incl ID, og i samme rækkefølge begge gange

dette er min syntaks efter verify, giver fejmeddelsen line 1: incorrect syntax near ',' når jeg forsøger at afvikle det. og der er ingen , i line 1
SET  IDENTITY_INSERT Hovedtabel1_backup ON
    INSERT     
    INTO  Hovedtabel1_backup(id, vkt_nr, billede, fil1, fil2, gruppe, undergruppe, ops_overvkt, ops_undervkt, anvendelse, bem_t_anv, totallaengde, delinger, bredde, hoejde, naeseRadius, hornimm, vinkel, sporbredde, forsaetn_prof_hoejde, tegningshenvisning, placering, reol, hylde, brugesaf, kunde, leverandor, rekvnr_pris, bem_t_vaerk, leveringsdato, udgaaet, udgaaetdato, ejer, betalingsandel, aktiv, sidstekontrol, notat, upsize_tz)                                    SELECT    (id, vkt_nr, billede, fil1, fil2, gruppe, undergruppe, ops_overvkt, ops_undervkt, anvendelse, bem_t_anv, totallaengde, delinger, bredde, hoejde, naeseRadius, hornimm, vinkel, sporbredde, forsaetn_prof_hoejde, tegningshenvisning, placering, reol, hylde, brugesaf, kunde, leverandor, rekvnr_pris, bem_t_vaerk, leveringsdato, udgaaet, udgaaetdato, ejer, betalingsandel, aktiv, sidstekontrol, notat, upsize_tz)
FROM        Hovedtabel1
WHERE    ID NOT IN
              (SELECT    ID
                FROM          Hovedtabel1_backup)
SET              IDENTITY_INSERT Hovedtabel1_backup OFF
jeg anvender version 5.0 til win2000

Nu kan jeg ikke teste det her, men i hvert fald skal kolonnelisten i anden halvdel ikke stå i parenteser

Har testet nu, det virker uden parentesen. Nu er du vel sikker på alle kolonnenavnene?

Det lykkedes, tak. Der var et par felter der var markeret specielt i databasen, men med copy-paste virkede det. SÅ kan jeg komme videre, dejligt.

Selv tak