Access 2 MySQL Upsizing

kan mysql ikke håndtere store sql filer ? hvad definerer du som stort her ?

en timestamp har pr default defaultværdien sat til now() - så det kan jeg heller ikke se skulle være et problem.

admin delen i MYSQL kløjs i den SQL fil, jeg har dannet for CREATE TABLES og INSERT INTO - den er for stor siger den selv ( ka ikke gemme) efter at have tygget meeeget længe på den ( Den var oprindelig ca 900 k og indeholdt bla. data på 2000 personer - nu er den delt op i mindre dele) Samme var gældende for php adminen på nettet. Det overraskede mig faktisk. M$ SQL trækker bare sådan noget ind.

Det er da rigtig, at TIMESTAMP ( den første af dem) i en record opdateres automatisk, men så skal du da alligevel ud og lave noget om og det er måske heller ikke hver gang now skal ind og min JAVASCRIPT for opdatering af datoen skulle alligevel laves om.

Ja og memo i Access blive i det script jeg bruger automatisk lavet om til LONGBLOB, som ikke kan assignes en String("varetelleandet"), så det må ændres til LONGTEXT og det giver ingen en forskel i  f.eks. søgerutiner.

Men du fattede vist ikke budskabet. Var der andre end mig, der havde brug for hånd igennem migreringen til MySQL ? Jamen undskyld jeg spurgte, jeg laver bare noget selv!

Henrik

hvorfor kan mysql ikke acceptere

rs.Fields('html') = String(Request.Form("html")).replace(re,"<scrip");
rs.Update();

men kun

sql = "UPDATE tblWebPage SET " +
"html=\"" + String(Request.Form("html")).replace(re,"<scrip")+ "\" " +

det giver nogle problemer med ' eller " i html delen læses som en SQL fejl

Henrik

har du overvejet at lave et sql dump du henter direkte ind gennem mysql's udemærkede mysqldump / mysql funktionalitet (jeg har hentet flere hundrede mb ind på dén måde) - jeg har på den måde hevet over 300.000 records ind i bruger databaser, langt flere i andre områder - den trækker tænder ud ligesom M$ SQL's DTP pakker

Kig evt. på http://www.mysql.com/doc/en/mysqldump.html (ja, det kræver commandline og kører både på windows og unix)

Du skriver memo, jeg kender ikke meget til Access, men en longtext kan indeholde små 4.294.967.295 tegn, måske der er en felttype der passer bedre ?

Hvis nu det var mig der skulle migrere din database ville jeg starte med at manuelt, fx i phpMyAdmin at oprette de tabeller du bruger blot med de små forskelle der findes (memo er en text osv.) Dernæst ville jeg i Access lave et udtræk der generer færdige SQL strenge, ala

INSERT INTO system_session VALUES
    (1, 0, '24a87124210166b23936c44c1e18f74d', '192.168.1.1', 20021002111537),
    (2, 0, '5876deae257102820232aa11fade9839', '192.168.1.2', 20021007182929),
    (3, 0, 'd1d5c970e76fe8d10117488e34418bf6', '192.168.1.3', 20021017173048),
    (4, 0, '5007febbd2715ceb63dbe92798527ece', '192.168.1.4', 20021030123014)
;

Ad din sidste kommentar - Eksperten er gratis og folk hjælper frivilligt, jeg tror der er rigtig svært at stille krav til løsninger og hvor hurtigt de skal leveres. Men det er selvfølgelig også kun min teori

>>ljweb Jeg tror vi taler forbi hinanden. Jeg tror ikke, at jeg har stillet krav til løsninger og hvor hurtigt sådan skulle leveres. Jeg er formodentlig ikke den enenste, der har arbejde i at konvertere og ville oprindeligt blot samle disse oplysninger/erfaringer et sted til glæde for andre.

Dit Mysql dump forslag er udmærket. Jeg har data inde på min udvikler maskine og mangler kun at få de tislvarende data ud hos ISPen ( A0.dk)
Som sagt sidder jeg og banker 60 record op ad gangen via et phpadmin for ikke at få sessionen til at time ud.

Nu jeg har dig - er UPDATE xx SET yy=zz den eneste måde, at man kan updatere og INSERT INTO xx VALUES (XX;YY)den eneste måde man indsætte en ny record i ASP til Mysql. Eller er det script jeg indtil nu har brugt kun noget Access fis?

Jeg sidder netop og uploader via CREATE TABE og senere INSERT INTO
Jeg har 2.000 personrecords og kæmper med en timeout hos A0.dk, når INSERT linierne kommer over de 100 - sight:
Status : 504 Gateway Time-Out
Description : Lost connection to neighbor proxy server

mht memo felter, disse er blot store tekstblokke, som vel en ovre grænse på 64 k alene på inputfeltets kapacitet. De konverterings rutiner, som jeg har pulset med oversætter MEMO til LONGBLOB. Denne og LONGTEXT har den samme tegnkapacitet, forskellen er - udover at den ikke modtager STRING() men vel binært og søgbarheden på store/små bogstaver.

Jeg prøver at samle de grene/træstammer man rammer ind i, første gang man konverterer til MySQL. Mit sidste problem for oven går på, at der i en html tekst ofte forekommer ' og " og det går ikke helt i SQL streng dannet via ASP. Jeg må finde en anden løsning også her, da opretning af record og opdatering af værdier i recorden ikke kan gøres via rs.Fields('html') og rs.Update()

Henrik

Jeg har lige erfaret, at

LOAD DATA INFILE 'file_name.txt'

skulle være lynhurtig

Henrik

Lige for at få lidt helt på det rene

Har du SSH access direkte til din udbyder ? eller sidder du og uploader gennem phpMyAdmin

Dine ' problemer rettes med at "slashe" dem, et ' skal således indsættes som \'.

Ad dine longblob/longtext felter, vil du med fordel kunne anvende text, der kan indeholde 64k tegn

Ad updates, så opdaterer du med UPDATE xxx SET yy=zz - dit eksempel er korrekt. I INSERT INTO, kan du vælge at angive feltnavne ved insert eller undlade dette. Du kan kun unlade, hvis dit antal variabler passer i rækkefølge og i antal med databasen. Hvis du navngiver, kan slipper du for at give null felter variabler

>>ljweb

Jeps - jeg har bare en billig en med phpMyAdmin og ikke en dedikeret.

phpMyAdmin har et interface, hvor du kan angive parametre til IMFILE kommandoen. Den bruger jeg næste gang. Jeg er bare vant til at bruge SQL filer for flytning af data. Jeg håber at indlæsning af CSV filer er hurtigere eller også har A0.dk sat deres phpAdmin til at time ud for hurtigt.
Det slog mig da også, at jeg dog kan bruge f.eks.  noget ala

var nyhtml = String(Request.Form("html")).replace("'","\'");
var nyhtml2= String(Request.Form("nyhtml")).replace('"','\"');

Jeg har dog ikke testet det endnu, da jeg var ude og buldre igår.

Det var jo oprindeligt ikke ment som et spørgsmål, hvor jeg skulle have svar på alskens problemer med min konvertering, men mere et spørgsmål om der var et behov for at samle de erfaringer jeg og andre har gjort under konvereteringen.

>> ljweb - Jeg syntes du har gjortr det godt ved at hænge på og svare, så du skulle da have et points for det, hvis du svarer.
Jeg får nok brug for dine og andre erfaring, men det skal være i regulære spørgsmål - ok

Henrik

phpMyAdmin lader meget være savnet og dens "load sql file" timer så hurtigt ud at man knapt når at aftale med basen hvad skal hvorhen før tiden er gået...

Men et generelt Access to mySQL merge kunne være et sjovt projekt - jeg har "heldigvis" ikke Access ;) men skal nok være med på at optimere mySQL enden skulle spørgsmålet engang komme. mySQL til Postgres, MSSQL/Sybase eller Oracle kunne være sjovere.

hov, glemte svaret

Vi er helt enige. Mange har Access på webbet for prisen er lav og det er nemt at gå. De fleste små webs klarer også sagtens belastningen på en Access 'db'. Jeg har da set op til 60 samtidige sessions.
Vi støder nok ind i hinanden ovre under MySQL.

Jeg synes det er en rigtig god med en Access -> MySQL tutorial . Det tror jeg mange kunne bruge, at dømme efter hvor ofte spørgsmålet optræder her på eksperten... Du kan evt. lægge linket her hvis du får det lavet :-)

>>msnilsson

Tja - der er jo løbet meget vand i Saraha siden jeg skrev det og kan vel næppe huske alle genvordighederne (Der var vist ikke så mange eller også læger tiden alle sår) - jeg er måske ikke den rigtige til det mere ( Ude af syne - ude af sind). MYSQL har kørt upåklageligt siden og der har ikke været de store problemer.

De ny udfordringer ligger i at anvende de nye MYSQL versioners muligheder.
Jeg har fulgt lidt med på sidelinien og fornemmer nogle 'migration' problemer.

MYSQL begynder at agere som M$SQL - jeg glæder mig til Stored procedures.