Binær datatype issue

[marradi]

Hei,

 

Vi jobber med et program på jobben, som skriver til og fra en access-database. Når vi åpner databasen for å se på tabellene så er det enkelte kolonner (for eksempel ID for noen tabeller, og dato) som kun består av kinesiske tegn. Datatypen er Binær.

 

Jeg er usikker på om det er blitt slik ved en feil, siden det kun er noen ID-kolonner som har denne datatypen.

 

Hvis det skal være sånn, hvordan forholder i oss til det hvis vi selv skal lage et program som skriver og leser fra databasen? Slet litt med å finne noe om det på Google.

[GeirGrusom]

Hei,

 

Vi jobber med et program på jobben, som skriver til og fra en access-database. Når vi åpner databasen for å se på tabellene så er det enkelte kolonner (for eksempel ID for noen tabeller, og dato) som kun består av kinesiske tegn. Datatypen er Binær.

 

Jeg er usikker på om det er blitt slik ved en feil, siden det kun er noen ID-kolonner som har denne datatypen.

 

Hvis det skal være sånn, hvordan forholder i oss til det hvis vi selv skal lage et program som skriver og leser fra databasen? Slet litt med å finne noe om det på Google.

Er de lagret som binærdata så er det opp til dere å bestemme hvordan de skal representeres.

[marradi]

Er de lagret som binærdata så er det opp til dere å bestemme hvordan de skal representeres.

 

Vi må jo returnere det tallet som det det opprinnelig ble lagret som. Bare lurer på om noen har vært borti noe lignende. Vet nemlig ikke om det har vært meningen å lagre dem som binært. Virker egentlig ganske meningsløst måten det er gjort på. ID'ene i den ene tabellen er lagret som tall, mens i en annen er de lagret som binært.

 

Er det veldig mange måter man egentlig kan konvertere det tilbake til et desimaltall?

Endret 8. februar 2013 av marradi

[GeirGrusom]

Vi må jo returnere det tallet som det det opprinnelig ble lagret som. Bare lurer på om noen har vært borti noe lignende. Vet nemlig ikke om det har vært meningen å lagre dem som binært. Virker egentlig ganske meningsløst måten det er gjort på. ID'ene i den ene tabellen er lagret som tall, mens i en annen er de lagret som binært.

 

Er det veldig mange måter man egentlig kan konvertere det tilbake til et desimaltall?

 

Hva er størrelsen på feltet? Jeg holder en knapp på 16 byte.

[marradi]

Hva er størrelsen på feltet? Jeg holder en knapp på 16 byte.

 

Du har helt rett. Det er mulig jeg stiller dumme spørsmål, men er litt noob når det gjelder dette.

[GeirGrusom]

Du har helt rett. Det er mulig jeg stiller dumme spørsmål, men er litt noob når det gjelder dette.

 

16-byte hentyder mot at dette representerer en Global Unique Identifier. Disse er 128-bit, og jeg tror ikke Access er istand til å benytte seg av det direkte. Men jeg har ikke hatt med Access å gjøre siden Access '97 så jeg er ikke helt oppdatert på området.

 

GUID/UUID-er som de kalles, har en spesiell egenskap som gjør dem nyttig i mange tilfeller: hver eneste genererte verdi er garantert unik selv om den er generert på forskjellige systemer. Dette gjør at en tabell med en GUID som primærnøkkel kan flette data fra en annen tabell fordi primærnøklene ikke kan kollidere. Dette gjør også at verdier som settes inn i databasen ikke kan fortelle rekkefølgen noe ble satt inn i (GUID-er er mer eller mindre vilkårlige)

GUID-er må ikke være CLUSTERED nøkler. Grunnen er at dette skaper ekstremt mye arbeid for databasemotoren hver gang en ny verdi blir satt inn.

 

Artikkelen nevnt over forklarer hvordan GUID-er som regel representeres.

Endret 8. februar 2013 av GeirGrusom

[marradi]

16-byte hentyder mot at dette representerer en Global Unique Identifier. Disse er 128-bit, og jeg tror ikke Access er istand til å benytte seg av det direkte. Men jeg har ikke hatt med Access å gjøre siden Access '97 så jeg er ikke helt oppdatert på området.

 

GUID/UUID-er som de kalles, har en spesiell egenskap som gjør dem nyttig i mange tilfeller: hver eneste genererte verdi er garantert unik selv om den er generert på forskjellige systemer. Dette gjør at en tabell med en GUID som primærnøkkel kan flette data fra en annen tabell fordi primærnøklene ikke kan kollidere. Dette gjør også at verdier som settes inn i databasen ikke kan fortelle rekkefølgen noe ble satt inn i (GUID-er er mer eller mindre vilkårlige)

GUID-er må ikke være CLUSTERED nøkler. Grunnen er at dette skaper ekstremt mye arbeid for databasemotoren hver gang en ny verdi blir satt inn.

 

Artikkelen nevnt over forklarer hvordan GUID-er som regel representeres.

 

Det du sier her virker veldig logisk. Det er en database som skal flettes sammen fra flere aktører i hele landet.

 

Tusen takk! Hjelper oss en del på veien.