---

Jeg har problemer med at eksportere en FileMaker database til MySQL {som
skal køre på en Synology diskstation 101g+, som kører Linux}

Jeg har eksporteret dataene i tabellen til MacRoman tab-format, hvilket
næppe er den rigtige, men der gives kun følgende optioner:

Windows (ANSI)
ASCII (DOS)
Macintosh
Unicode (UTF-16)
Japanese (Shift-JIS)

- for tegnsættet, og MySQLs load-facilitet kræver brugen af
tab-separerede filer, hvor tomme felter markeres med et \n, så derfor
har jeg derefter åbnet den tabseparerede fil i Excel, og erstattet alle
tomme felter med \n i feltet. For at sikre at der ikke mangler tomme
felter sidst i tabellen [til højer], er den primære nøgle placeret
sidst, så tabellen i MySQL er defineret således:

mysql> create table i (titel varchar(20), fornavn varchar(20), efternavn
varchar(30), kommentar varchar(50), fortroligt varchar(50), pk integer);
Query OK, 0 rows affected (0.09 sec)

mysql> load data local infile 'att.txt' into table i lines terminated by
'\r';Query OK, 1404 rows affected, 259 warnings (0.40 sec)
Records: 1404 Deleted: 0 Skipped: 0 Warnings: 259

mysql> select fornavn, efternavn from i;
....
| K?benhavns Politi St |
|
| virtualCD |
|
| QuicKeys |
|
| cykel |
|
| MidtData |
|
| Hovedstadens Ejendom |
|
| Bauerseind |
|
| Frederiksborg amt
L? |
|
| Apple Computer |
|
| Astrid | Bauchm?ller |
| Wolfram Research |
|
|
|
|
| Peter | Randl?v |
| Karen | Seiersen |
+----------------------+--------------------+
1404 rows in set (0.27 sec)

Dropper jeg det \n som i MySQL-manualen nævnes som nødvendig, får jeg
dog i stedet følgende:

| K?benhavns Politi St | |
| virtualCD | |
| QuicKeys | |
| cykel | |
| MidtData | |
| Hovedstadens Ejendom | |
| Bauerseind | |
| Frederiksborg amt
L? | |
| Apple Computer | |
| Astrid | Bauchm?ller |
| Wolfram Research | |
| | |
| Peter | Randl?v |
| Karen | Seiersen |
+----------------------+--------------------+
1404 rows in set (0.27 sec)

mysql>

==

Hvilket må indicere at sådanne ikke er nødvendige, samt vel i øvrigt at
der findes linieskift i enkelte felter [en gennemgang af selve databasen
viser fejl i enkelte poster, som jeg retter manuelt].

--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Windows (ANSI)

Det er nok denn her du skal bruge.

> Hvilket må indicere at sådanne ikke er nødvendige, samt vel i øvrigt
> at der findes linieskift i enkelte felter [en gennemgang af selve
> databasen viser fejl i enkelte poster, som jeg retter manuelt].

Jeg begriber ikke hvad det er du er utilfreds med - forklar eventuelt
igen.

Ellers så er der vel en JDBC-driver til Filemaker, så kan du bruge
DBvisualizer til at analysere tingene med.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Windows (ANSI)
>
> Det er nok den her du skal bruge.

Det var det - ikke.

> > Hvilket må indicere at sådanne ikke er nødvendige, samt vel i øvrigt
> > at der findes linieskift i enkelte felter [en gennemgang af selve
> > databasen viser fejl i enkelte poster, som jeg retter manuelt].

> Jeg begriber ikke hvad det er du er utilfreds med - forklar eventuelt
> igen.

Jeg opdagede såmænd blot mens jeg skrev indlægget, at de \n'er i de
tomme felter, som MySQL-manualen foreskrev, ikke var nødvendig, samt at
jeg manuelt måtte foretage visse rettelser i databasen.

> Ellers så er der vel en JDBC-driver til Filemaker, så kan du bruge
> DBvisualizer til at analysere tingene med.

Noget sådant er ikke nødvendigt.
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> > Ellers så er der vel en JDBC-driver til Filemaker, så kan du bruge
> > DBvisualizer til at analysere tingene med.
>
> Noget sådant er ikke nødvendigt.

Det kommer da an på om du kan få det andet til at virke.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > > Ellers så er der vel en JDBC-driver til Filemaker, så kan du bruge
> > > DBvisualizer til at analysere tingene med.
> >
> > Noget sådant er ikke nødvendigt.
>
> Det kommer da an på om du kan få det andet til at virke.

Nu kender jeg ikke DBvisualizer, men jeg troede kun at den kunne bruges
til at rette nogle småfejl med?
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Nu kender jeg ikke DBvisualizer, men jeg troede kun at den kunne
> bruges til at rette nogle småfejl med?

Jeg tror egentlig ikke det er et værktøj for dig, i betragtning af
hvad du ellers har problemer med.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Per Rønne <per@RQNNE.invalid> wrote:

> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
>
> > per@RQNNE.invalid (Per Rønne) writes:
> >
> > > Windows (ANSI)
> >
> > Det er nok den her du skal bruge.
>
> Det var det - ikke.

Den er vist lidt vanskeligere end jeg regnede med.

Når jeg eksporterer FM-dataene til ASCII (DOS), og gemmer filen på en
Windows-maskine, og når jeg så importerer dem fra Windåsen, så viser
mysql dem korrekt på Windåsen, men forkert på mac'en.

Selve MySQL-databasen ligger så på en tredie maskine.

FM kan eksportere dem i UTF-16 men MySQL kan tilsyneladende kun klare
UTF-8 [en bunke forskellige typer].
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Windows-maskine, og når jeg så importerer dem fra Windåsen, så viser
> mysql dem korrekt på Windåsen, men forkert på mac'en.

Tjah, det lyder som et tegnsætproblem. Mon ikke du har glemt at
fortælle Mac'en at den skal køre ISO-Latin-1 istedet for Mac Roman?

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Windows-maskine, og når jeg så importerer dem fra Windåsen, så viser
> > mysql dem korrekt på Windåsen, men forkert på mac'en.
>
> Tjah, det lyder som et tegnsætproblem. Mon ikke du har glemt at
> fortælle Mac'en at den skal køre ISO-Latin-1 istedet for Mac Roman?

Jeg aner ikke engang hvor man skulle kunne »fortælle« mac'en det. Jeg
har regnet med at det var applikations-afhængigt {som MacSOUP med
MacRoman}, og jeg ser at man kan sætte tilsyneladende alle tegnpalettens
tegn ind i Terminal.app.

I Terminal.>Arkiv->Info->Skærm ser jeg i øvrigt at unicode-8 er slået
til. Når jeg indstiller til andre koder kommer jeg til at se andre tegn
fra en forsøgstabel, jeg har lavet, når jeg indtaster mit efternavn. Men
ingen af dem gengives korrekt på Windåsen. Heller ikke når jeg vælger
'Vesteuropæisk (Windows Latin 1)'. Derudover kan jeg som nævnt indstille
selve MySQL til et utal af tegnkoder, hvoraf de fleste dog umiddelbart
kan udelukkes.

På nuværende tidspunkt vises følgende opsætninger:

character set client utf8
(Global værdi) latin1
character set connection utf8
(Global værdi) latin1
character set database latin1
character set results utf8
(Global værdi) latin1
character set server latin1
character set system utf8
character sets dir /usr/syno/mysql/share/mysql/charsets/
collation connection utf8_danish_ci
(Global værdi) latin1_swedish_ci
collation database latin1_swedish_ci
collation server latin1_swedish_ci

Da jeg ikke kan telnette til synology-diskstationen, kan jeg naturligvis
heller ikke komme ind i /usr/syno/mysql/share/mysql/charsets/
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> > Tjah, det lyder som et tegnsætproblem. Mon ikke du har glemt at
> > fortælle Mac'en at den skal køre ISO-Latin-1 istedet for Mac Roman?
>
> Jeg aner ikke engang hvor man skulle kunne »fortælle« mac'en det. Jeg
> har regnet med at det var applikations-afhængigt {som MacSOUP med
> MacRoman}, og jeg ser at man kan sætte tilsyneladende alle tegnpalettens
> tegn ind i Terminal.app.

Det er det da også. Jeg går ud fra du sidder i Terminal.app, og der
sættes det i indstilinger.

På nuværende tidspunkt skal du beslutte dig for hvad du vil køre din
database i - jeg foreslår iso-8859-1 (som modsvarer codepage 1252) -
og så sætte Terminal.app til dét. Dette er naturligvis begrundet af
at det er rigtigt på din Windows.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > > Tjah, det lyder som et tegnsætproblem. Mon ikke du har glemt at
> > > fortælle Mac'en at den skal køre ISO-Latin-1 istedet for Mac Roman?
> >
> > Jeg aner ikke engang hvor man skulle kunne »fortælle« mac'en det. Jeg
> > har regnet med at det var applikations-afhængigt {som MacSOUP med
> > MacRoman}, og jeg ser at man kan sætte tilsyneladende alle tegnpalettens
> > tegn ind i Terminal.app.
>
> Det er det da også. Jeg går ud fra du sidder i Terminal.app, og der
> sættes det i indstilinger.
>
> På nuværende tidspunkt skal du beslutte dig for hvad du vil køre din
> database i - jeg foreslår iso-8859-1 (som modsvarer codepage 1252) -
> og så sætte Terminal.app til dét. Dette er naturligvis begrundet af
> at det er rigtigt på din Windows.

Det forsøger jeg så i morgen. Systemet står over for en automatisk
Retrospect backup, og det kan være smart at udskyde det til i morgen ved
at lukke mac'en ned.

Især når jeg tilsyneladende har fået lidt feber - en kraftig forkølelse
;-(.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > > Tjah, det lyder som et tegnsætproblem. Mon ikke du har glemt at
> > > fortælle Mac'en at den skal køre ISO-Latin-1 istedet for Mac Roman?
> >
> > Jeg aner ikke engang hvor man skulle kunne »fortælle« mac'en det. Jeg
> > har regnet med at det var applikations-afhængigt {som MacSOUP med
> > MacRoman}, og jeg ser at man kan sætte tilsyneladende alle tegnpalettens
> > tegn ind i Terminal.app.
>
> Det er det da også. Jeg går ud fra du sidder i Terminal.app, og der
> sættes det i indstilinger.
>
> På nuværende tidspunkt skal du beslutte dig for hvad du vil køre din
> database i - jeg foreslår iso-8859-1 (som modsvarer codepage 1252) -

Og vel det der i MySQLs phpMyAdmin kaldes latin1_bin.
Nu er MySQL sat op til det.

> og så sætte Terminal.app til dét. Dette er naturligvis begrundet af
> at det er rigtigt på din Windows.

Og her har jeg nu valgt »Vesteuropæisk (Windows Latin 1)«.

Så må vi se hvordan det går.

Og det synes ikke at have ændret sig. På Mac'en, i Terminal, fås:

mysql> select * from navne;
+-------+
| navn |
+-------+
| Rønne |
+-------+
1 row in set (0.04 sec)

mysql>

Tilsvarende i kommandopromptet i Windows fås efternavnet til R°nne ...
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Tilsvarende i kommandopromptet i Windows fås efternavnet til R°nne ...

Prøv at køre chcp 1252 først.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Tilsvarende i kommandopromptet i Windows fås efternavnet til R°nne ...
>
> Prøv at køre chcp 1252 først.

Sammme resultat.
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> > Prøv at køre chcp 1252 først.
>
> Sammme resultat.

Nå, men så har jeg ikke flere gode ideer.

Find først ud af hvad præcis der ligger i databasen - så kan du
diagnosticere videre derfra.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > > Prøv at køre chcp 1252 først.
> >
> > Sammme resultat.
>
> Nå, men så har jeg ikke flere gode ideer.
>
> Find først ud af hvad præcis der ligger i databasen - så kan du
> diagnosticere videre derfra.

Jep. Og måske skal jeg også først lige have en side, hvor jeg får det ud
gennem en browser.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne <per@RQNNE.invalid> wrote:

> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
>
> > Find først ud af hvad præcis der ligger i databasen - så kan du
> > diagnosticere videre derfra.
>
> Jep. Og måske skal jeg også først lige have en side, hvor jeg får det ud
> gennem en browser.

Det kan jo give nye interessante problemer med din tegntabel. Hvilken
tegntabel bruges i PHP? I Apache? I din browser? Jeg ville vente med
det, indtil du har fået det grundlæggende til at virke.

Jeg har forstået, at du ikke har telnet-adgang til din Linux-boks. Har
du installeret MySQL-klienten på både din Win-bog og din Mac?

Du bør nok studere lidt, hvilke tegntabeller disse klienter kører.
(Afsnittet om tegntabeller i MySQL-manualen er ret langt, og jeg har det
ikke på rygraden, så jeg kan ikke lige huske hvordan.)

Du skriver et sted, at 'Rønne' på Mac bliver til 'R°nne' på Win. Den
fejl plejer at skyldes, at 'ø' bliver gemt i ISO-8859-1 som 0xF8 og
derefter vist i en gammel DOS-tegntabel, hvor 0xF8 netop bruges til
grad-tegnet. Fejlen ligger sikkert i din Win-bog.

--
Thorkil Olesen,
Hanstholm.

---

Thorkil Olesen <slet.dette.thorkil.og.dette@pip.dknet.dk> wrote:

> Per Rønne <per@RQNNE.invalid> wrote:
>
> > Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
> >
> > > Find først ud af hvad præcis der ligger i databasen - så kan du
> > > diagnosticere videre derfra.
> >
> > Jep. Og måske skal jeg også først lige have en side, hvor jeg får det ud
> > gennem en browser.
>
> Det kan jo give nye interessante problemer med din tegntabel. Hvilken
> tegntabel bruges i PHP? I Apache? I din browser? Jeg ville vente med
> det, indtil du har fået det grundlæggende til at virke.

Det tror jeg også at jeg vil.

> Jeg har forstået, at du ikke har telnet-adgang til din Linux-boks.

Korrekt. Jeg har adgang til MySQL gennem phpmyAdmin, og det er
derigennem at jeg har kunnet give mig selv en mere direkte adgang til
MySQL, også fra andre maskiner. Jeg kan ikke gøre det samme med den
PostgreSQL der også er installeret på netværksdrevet, som det også kan
ses på:

<http://www.RQNNE.dk/phpinfo>

> Har du installeret MySQL-klienten på både din Win-bog og din Mac?

På min Windows-desktop {der ellers stort set er degraderet til
harddisk-optager, efter at jeg har installeret tv- og radiotunerkort i
den} og på min G4/867.

> Du bør nok studere lidt, hvilke tegntabeller disse klienter kører.
> (Afsnittet om tegntabeller i MySQL-manualen er ret langt, og jeg har det
> ikke på rygraden, så jeg kan ikke lige huske hvordan.)

Jep, og jeg har ikke engang kørt MySQL 4.1.15-manualen ud {ja, det er
denne lidt gamle version uden views {;-(} der er installeret} - men jeg
har lige bestilt et genopfyldningssæt af toner til min LaserJet 4050N
printer {den som nogle altid husker er forsynet med en duplex-enhed}.

> Du skriver et sted, at 'Rønne' på Mac bliver til 'R°nne' på Win. Den
> fejl plejer at skyldes, at 'ø' bliver gemt i ISO-8859-1 som 0xF8 og
> derefter vist i en gammel DOS-tegntabel, hvor 0xF8 netop bruges til
> grad-tegnet. Fejlen ligger sikkert i din Win-bog.

Lad os håbe at den kun bliver gemt der. Men din antagelse underbygges i
hvert fald af at hvis jeg kører data ud fra FileMaker i »ASCII (DOS)« så
vises den korrekt på MySQL på Windåsen, men ikke på Mac'en. I så fald
lader jeg den ind gennem Windåsen.
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> > > Tilsvarende i kommandopromptet i Windows fås efternavnet til R°nne ...
> >
> > Prøv at køre chcp 1252 først.
>
> Sammme resultat.

Bare lige for at få det på det rene. Du kører Start->Kør og vælger
"cmd", og i den opståede kommandoshell angiver du først

chcp 1252

og hernæst

mysql ......


--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > > > Tilsvarende i kommandopromptet i Windows fås efternavnet til R°nne ...
> > >
> > > Prøv at køre chcp 1252 først.
> >
> > Sammme resultat.
>
> Bare lige for at få det på det rene. Du kører Start->Kør og vælger
> "cmd", og i den opståede kommandoshell angiver du først
>
> chcp 1252
>
> og hernæst
>
> mysql ......

Næ, jeg starter kommandopromptet, skriver chp 1252, vognretur, og
derefter mysql -h 10.0.0.33 -p ...

Men jeg kan se at dit forslag giver lettere adgang til kommandopromptet
.... end at skulle ind gennem Programmer->Tilbehør.
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Næ, jeg starter kommandopromptet, skriver chp 1252, vognretur, og
> derefter mysql -h 10.0.0.33 -p ...

Min diagnose er at du ikke har fået det ind i iso-latin-1.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Næ, jeg starter kommandopromptet, skriver chp 1252, vognretur, og
> > derefter mysql -h 10.0.0.33 -p ...
>
> Min diagnose er at du ikke har fået det ind i iso-latin-1.

Snakker du nu om når jeg ad forskellige veje har loaded en tabel ind,
eller den forsøgstabel jeg har lagt ind, hvor jeg på mac'en har lagt
navnet 'Rønne' ind, og på windåsen læser 'R°nne'?

I øvrigt opdager jeg nu at jeg i kommandopromptet også får '°' from når
jeg trykker på 'ø', mens æ og å giver µ og õ?
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> I øvrigt opdager jeg nu at jeg i kommandopromptet også får '°' from når
> jeg trykker på 'ø', mens æ og å giver µ og õ?

Måske er det tiden til at du skriver lidt færre indlæg, og indsamler
nogen flere empiriske data?

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Hej Per

Per Rønne wrote:
> Jeg har problemer med at eksportere en FileMaker database til MySQL {som
> skal køre på en Synology diskstation 101g+, som kører Linux}
>
> Jeg har eksporteret dataene i tabellen til MacRoman tab-format, hvilket
> næppe er den rigtige, men der gives kun følgende optioner:

IFM6/7 under 'Export Records'? - det findes ikke!

I Filemaker 6.x/7.x har du følgende valgmuligheder:
- Tab-Separated-Text
- Comma-Separated-Text
- SYLK
- DBF
- DIF
- WKS 1)
- BASIC 2)
- Merge
- HTML Table
- Filemaker Pro 3)
- XML 4)

1) = Microsoft Works format
2) = RealBASIC hexadecimal separated text groups (ASCII/ANSI)
Vælger du det format, mister du æøåÆØÅ
3) = Så det kan importeres til ældre FMP fra 1.0-5.5
4) = Dog kun fra og med FM7

NB. Der findes en FM extension, der også tillader at eksportere direkte
til Excel og Access format, så man er fri for at skulle omkring XML. Her
bliver 'eksporten' så blive gemt som en Excel eller Access fil, der kan
åbnes direkte i disse to. Svjv. ligger de et eller andet sted på
Microsofts hjemmeside til gratis download, men hidtil har jeg ikke
kunnet finde dem.

> Windows (ANSI)
> ASCII (DOS)
> Macintosh
> Unicode (UTF-16)
> Japanese (Shift-JIS)

Hm, - er det 'Import' i MySQL? - Ingen af disse findes faktisk i FM...

> - for tegnsættet, og MySQLs load-facilitet kræver brugen af
> tab-separerede filer, hvor tomme felter markeres med et \n, så derfor
> har jeg derefter åbnet den tabseparerede fil i Excel, og erstattet alle
> tomme felter med \n i feltet. For at sikre at der ikke mangler tomme
> felter sidst i tabellen [til højer], er den primære nøgle placeret
> sidst, så tabellen i MySQL er defineret således:

Jeg har meget lidt kendskab til SQL på OS X, men lidt og mere til 4th
Dimension på OS 9.x, og ud fra det, du beskriver, ligner SQL lidt 4D i
samme retning.

Så du skal i FM vælge 'Export Records' -> 'Tab-Separated-Text', og i
MySQl vælge 'Import Files' - ikke 'Import Database'.

> mysql> create table i (titel varchar(20), fornavn varchar(20), efternavn
> varchar(30), kommentar varchar(50), fortroligt varchar(50), pk integer);
> Query OK, 0 rows affected (0.09 sec)
>
> [beskrivelse af MySQL opbygning]
>
> Hvilket må indicere at sådanne ikke er nødvendige, samt vel i øvrigt at
> der findes linieskift i enkelte felter [en gennemgang af selve databasen
> viser fejl i enkelte poster, som jeg retter manuelt].

Import funktionen skulle meget gerne generere et felt af samme type for
hvert enkelt tab som i det oprindelige, men der vil altid være noget
manulet tilretning. Hverken SQL eller 4D kan generere felterne i
nøjagtig samme layout som de oprindelige. Så det vil nok være en fordel,
at du i forvejen laver en tom SQLs base, der er opbygget, som du vil
have den og derefter vælge 'Import Files' til de respektive felter.

Bemærk at samtlige semi- og full-relations forsvinder ved brugen af
'Tab-Separated-Text' eksportering.

Hm, fnadt lige 'FmPro Migrator', der tillader direkte eksport til MySQL
<http://www.fmpromigrator.com/products/fmpro_migrator/index.html>
- Og 'fmSQL Synch 2.0b12', der tillader direkte sync af FM databaser til
MySQL <http://www.garrison.com.au/products/fmsql_synch.html>.

Ud fra en hurtig skumning af omtalen er det nok den sidste, der er mest
velegnet.

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> > Jeg har eksporteret dataene i tabellen til MacRoman tab-format, hvilket
> > næppe er den rigtige, men der gives kun følgende optioner:
>
> IFM6/7 under 'Export Records'? - det findes ikke!

FM 7.

> I Filemaker 6.x/7.x har du følgende valgmuligheder:
> - Tab-Separated-Text

Og derefter kan man vælge hvilken tegnkode man vil eksportere i.

> Hm, - er det 'Import' i MySQL? - Ingen af disse findes faktisk i FM...

I MySQL definerer man først tabellen, og så foretager man en:

LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name'
[REPLACE | IGNORE]
INTO TABLE tbl_name
[FIELDS
[TERMINATED BY 'string']
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
]
[LINES
[STARTING BY 'string']
[TERMINATED BY 'string']
]
[IGNORE number LINES]
[(col_name,...)]
==

Du kan se mere om det på online-manualen:

<http://dev.mysql.com/doc/refman/4.1/en/load-data.html>

Så det er altså kun selve tabellerne, med deres primære og fremmede
nøgler, der eksporteres til MySQL. Problemet er nu så bare de hulens
mange forskellige tegnsæt, og samarbejdet mellem dem på tre forskellige
platforme - Windows XP Pro, MacOS X 10.4.6 og en Linux og PPC baseret
netværksharddisk.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Hej Per

Per Rønne wrote:
>Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:
>>>Jeg har eksporteret dataene i tabellen til MacRoman tab-format, hvilket
>>>næppe er den rigtige, men der gives kun følgende optioner:
>>
>>IFM6/7 under 'Export Records'? - det findes ikke!
>
> FM 7.
>
>>I Filemaker 6.x/7.x har du følgende valgmuligheder:
>>- Tab-Separated-Text
>
> Og derefter kan man vælge hvilken tegnkode man vil eksportere i.

Mystisk... Den funktion har jeg ikke i min FM 7.0.3. - Er det server-
eller developerversionen, du har?

>>Hm, - er det 'Import' i MySQL? - Ingen af disse findes faktisk i FM...
>
> I MySQL definerer man først tabellen, og så foretager man en:
>
> LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name'
> [REPLACE | IGNORE]
> INTO TABLE tbl_name
> [FIELDS
> [TERMINATED BY 'string']
> [[OPTIONALLY] ENCLOSED BY 'char']
> [ESCAPED BY 'char']
> ]
> [LINES
> [STARTING BY 'string']
> [TERMINATED BY 'string']
> ]
> [IGNORE number LINES]
> [(col_name,...)]
> ==
>
> Du kan se mere om det på online-manualen:
>
> <http://dev.mysql.com/doc/refman/4.1/en/load-data.html>

OK, det minder en del om 4D...

> Så det er altså kun selve tabellerne, med deres primære og fremmede
> nøgler, der eksporteres til MySQL. Problemet er nu så bare de hulens
> mange forskellige tegnsæt, og samarbejdet mellem dem på tre forskellige
> platforme - Windows XP Pro, MacOS X 10.4.6 og en Linux og PPC baseret
> netværksharddisk.

Ja, og umiddelbart kan jeg ikke finde et sted i FM, hvor man kan ændre
tegnsæt...

mvh. ERik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> Ja, og umiddelbart kan jeg ikke finde et sted i FM, hvor man kan ændre
> tegnsæt...

vælg File->Eksport Records->Tab-separated Text

Save et fornuftigt sted, og med et fornuftigt navn.

Du kommer så ind i Specify Field Order for Export, og nederst ser du en
pop-up menu hvor du kan vælge fem forskellige tegnsæt. Der står »Outpun
file character set« ved den.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Hej Per

Per Rønne wrote:
>Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:
>>Ja, og umiddelbart kan jeg ikke finde et sted i FM, hvor man kan ændre
>>tegnsæt...
>
> vælg File->Eksport Records->Tab-separated Text
>
> Save et fornuftigt sted, og med et fornuftigt navn.

Jep, det er også det, jeg gør, men af gammel vane plejer jeg blot at
klikke hurtigt 2 gange på 'ENTER'...

> Du kommer så ind i Specify Field Order for Export, og nederst ser du en
> pop-up menu hvor du kan vælge fem forskellige tegnsæt. Der står »Outpun
> file character set« ved den.

Det er så her, det går 'skævt'. - som sagt plejer jeg altid blot at
klikke 'ENTER' 2 gange, og jeg åbner så den database, der skal
importeres _til_ og vælger import og lade den bestemme import-orden.

Den står, som du skriver til 'Macintosh', men jeg har været ved at kigge
i min FMP 5.5, her har jeg sat den til ASCII-DOS. Det plejer at virke
udmærket - bortset fra æøå, hvis jeg får Excel/Access tabseperated
filer, så forsvinder æøå og erstattes med det omvendte spørgsmålstegn.
Men at rette det er blot at køre en konventionel Find/Replace. - Har
ikke prøvet det endnu i FM 7, men i de ældre erstatter den kun i samme
felt i hele basen, og så er det jo blot at finde næste felt, hvor det er
galt og køre samme procedure...

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> Den står, som du skriver til 'Macintosh', men jeg har været ved at kigge
> i min FMP 5.5, her har jeg sat den til ASCII-DOS. Det plejer at virke
> udmærket - bortset fra æøå, hvis jeg får Excel/Access tabseperated
> filer, så forsvinder æøå og erstattes med det omvendte spørgsmålstegn.
> Men at rette det er blot at køre en konventionel Find/Replace. - Har
> ikke prøvet det endnu i FM 7, men i de ældre erstatter den kun i samme
> felt i hele basen, og så er det jo blot at finde næste felt, hvor det er
> galt og køre samme procedure...

Eksporterer jeg i ascii-dos til en Windows-maskine, og importerer jeg
fra Windåsen til mysql kommer tegnene korrekt over, og æøå vises korrekt
på Windåsen.

Men ikke på mac'en, så det er på mac'en jeg skal ændre indstillingerne
for Terminal, og på Synology'en jeg skal ændre det samme, så det kører
med samme tegnsæt.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Hej Per

Per Rønne wrote:
>Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:
>>Den står, som du skriver til 'Macintosh', men jeg har været ved at kigge
>>i min FMP 5.5, her har jeg sat den til ASCII-DOS. Det plejer at virke
>>udmærket - bortset fra æøå, hvis jeg får Excel/Access tabseperated
>>filer, så forsvinder æøå og erstattes med det omvendte spørgsmålstegn.
>>Men at rette det er blot at køre en konventionel Find/Replace. - Har
>>ikke prøvet det endnu i FM 7, men i de ældre erstatter den kun i samme
>>felt i hele basen, og så er det jo blot at finde næste felt, hvor det er
>>galt og køre samme procedure...
>
> Eksporterer jeg i ascii-dos til en Windows-maskine, og importerer jeg
> fra Windåsen til mysql kommer tegnene korrekt over, og æøå vises korrekt
> på Windåsen.

- Og det er lidt bøvlet med en 'dobbelt-tur'. - Har du prøvet med
'Comma-Separated-Text'? - Svjh. er den mere 'Excel-venlig', og som jeg
umiddelbart har læst det, så er MySQL ganske kompatibel med Excel...

> Men ikke på mac'en, så det er på mac'en jeg skal ændre indstillingerne
> for Terminal, og på Synology'en jeg skal ændre det samme, så det kører
> med samme tegnsæt.

Ja, og her står jeg af! - Linux+netværksdiske er ikke noget, jeg
overhovedet har prøvet - heller ikke læst noget om.

Men hvor ville det være en god idé, hvis Filemaker fik et integreret
TextEncoding system som mange TB programmer har det, så ville
problemerne være væk...

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> - Og det er lidt bøvlet med en 'dobbelt-tur'. - Har du prøvet med
> 'Comma-Separated-Text'? - Svjh. er den mere 'Excel-venlig', og som jeg
> umiddelbart har læst det, så er MySQL ganske kompatibel med Excel...

Da det viste sig at det slet ikke var nødvendigt med \n'er i tomme
felter, så har jeg droppet omvejen over Excel.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> Hm, fnadt lige 'FmPro Migrator', der tillader direkte eksport til MySQL
> <http://www.fmpromigrator.com/products/fmpro_migrator/index.html>
> - Og 'fmSQL Synch 2.0b12', der tillader direkte sync af FM databaser til
> MySQL <http://www.garrison.com.au/products/fmsql_synch.html>.

Men det kan da være at sådanne programmer kan gøre det lidt lettere. Men
det løser nu næppe tegnsæts-problemerne.

Og så er det jo betale-software ...
--
Per Erik Rønne
http://www.RQNNE.dk