Data Overflow bij export van MS SQL Server naar MySQL

[Verwijderd]

Hoi!

Ik ben momenteel bezig met het synchroniseren van een MySQL database met een MS SQL Server database. Ik gebruik hiervoor de DTS-functies van MS SQL Server. Op zich werkt dit allemaal aardig, ik kan een package schedulen en dergelijke, dat werkt allemaal. De tabel die ik wil exporteren vanuit SQL Server naar MySQL wordt netjes aangemaakt in MySQL, dus dat is ook okee, maar dan komen er toch problemen.

Wil ik namelijk velden overhevelen waarvan het datatype ingesteld staat op int of in ieder geval een getalwaarde, dan gaat het goed, maar wil ik teksten of karakters overhevelen dan gaat het helemaal mis.

In SQL Server heb ik bijvoorbeeld een paar velden met een karakterlengte van 12, die exporteer ik naar MySQL mbv MyODBC (DTS maakt keurig een tabel aan in MySQL, of tenminste hij zorgt ervoor dat deze klaarstaat aan de andere kant van de lijn). De velden van deze tabel staan ook ingesteld op 12 karakters veldlengte, maar toch krijg ik bij de DTS-wizard een foutmelding:

Insert error, column 1 ('blabla',DB_TYPESTR),status 6: Data overflow

Omdat de foutmelding een data overflow aangeeft, heb ik bij de exporteerwizard tussentijds aangegeven dat de destination veldtypes een wat grotere capaciteit kunnen bevatten (bijvoorbeeld 14), maar nog krijg ik dezelfde melding. Ook heb ik geprobeerd om het destination-veldtype van char naar text te veranderen, maar dan krijg ik weer de volgende foutmelding:
Query-based insertion or updating of BLOB values is not supported

Ik snap er geen hout van. Volgens mij is dit net zoiets als een fiets die in een fietsenstalling staat te verplaatsen naar een parkeerplaats voor een auto en dat er gezegd wordt dat die nieuwe parkeerplaats te klein is voor die fiets...

Heeft iemand een idee wat hier aan de hand is? Ik heb al weet ik veel hoeveel forums afgestruind, maar ik kom er niet uit.

Kan iemand me helpen?

Alvast bedankt

P.S. Sorry van de lengte

[Annie]

Kan het niet zijn dat de myODBC een beetje brak is? Ik heb er zelf geen ervaring mee, maar ik zie af en toe berichten waarbij ik mij niet aan deze indruk kan onttrekken. Als het klok-klepel cq. broodje aap verhalen zijn dan mijn excuses (ook voor het feit dat ik ze nu dus zelf ook weer verder de wereld in help ).
Het lijkt er een beetje op dat de vertaling van de datatypes niet helemaal vlotjes verloopt. Heb je al geprobeerd te converteren naar een varchar (bijv: varchar(4000) ofzo)?

Een mogelijke oplossing (alhoewel het een hoog houtje-touwtje gehalte heeft) is DTS laten exporteren naar een text bestand en deze laten importeren door de import utility van MySQL.

[Verwijderd]

Hoi Annie,

Ik denk dat je idd gelijk hebt dat de MyODBC een beetje brak is, of misschien juist wel DTS... Microsoft he?
Wat je voorstelt om varchar in te stellen op 4000 pikt DTS niet, ik krijg dan een "Niet nader omschreven fout" en dan lukt het niet meer om "OK" te klikken. Dat werkt dus niet.

Wat betreft het exporteren naar een textbestand, dat was onze eerste ingeving ook wel, maar we moeten een zeer grote database filteren (paar honderd tabellen, met duizenden records), daarom wilden we juist DTS gebruiken om dit allemaal wat makkelijker te maken. Bovendien kun je deze procedures op laten slaan als package en die kun je weer schedulen.

Als je eerst exporteert naar tekst en je moet het dan weer op een webserver importeren, dan moet dit ook automatisch kunnen gebeuren. Die webserver staat namelijk in België. In zo'n geval...biedt MySQL dan ook een soort automatische taken die elke nacht bijvoorbeeld uitgevoerd worden?
In ieder geval al bedankt voor de reply.

[Annie]

Verwijderd schreef op 17 maart 2003 @ 14:08:
of misschien juist wel DTS... Microsoft he?

Tsss, let op je woorden

Verwijderd schreef op 17 maart 2003 @ 14:08:
Als je eerst exporteert naar tekst en je moet het dan weer op een webserver importeren, dan moet dit ook automatisch kunnen gebeuren. Die webserver staat namelijk in België. In zo'n geval...biedt MySQL dan ook een soort automatische taken die elke nacht bijvoorbeeld uitgevoerd worden?

Je kan de export naar textfile ook opslaan als package. Als je deze package daarna edit kan je een FTP task toevoegen waarmee het tekstbestand overgezet wordt naar de webserver (mits je SQL2000 hebt) en eventueel nog wat andere taken (bijvoorbeeld een mailtje om te melden dat de export gelukt is, of juist niet ).

Op de webserver kan je met een scheduler de import op MySQL regelen (bijv via cron als het een linux-bak is).

[ACM]

MySQL kan ook helemaal geen varchars van 4000 aan dus dat heeft weinig nut. De maximale lengte is 256 karakters...
Sterker nog, MySQL denkt graag met je mee en als jij een char van meer dan 4 karakters opgeeft maakt ie er automatisch en varchar van... Enige 'nadeel' is dat ie dan niet ook meer dan dat kan accepteren, dus als je 6 tekens invoert als string, neemt ie 4 tekens over en de rest negeert ie...
Mysql kent bij mijn weten ook helemaal geen "data overflows", dat negeert ie gewoon. Die melding zal dus wel ergens onderweg opgegooid worden?

Hoe goed/slecht MyODBC zelf is weet ik niet, maar ik weet wel dat SQL Server's output kwa flatfile-sql iig niet rechtstreeks MySQL in kan, iig met versie 7 kon dat niet Dat kan uiteraard ook door mijn gebrek aan kennis van MSSQL gelegen hebben

offtopic:
Als je van mysql af wilt, kijk es naar postgresql

[ Voor 15% gewijzigd door ACM op 17-03-2003 17:49 ]

[Verwijderd]

Hoi Annie en ACM,

Ik wil jullie even bedanken voor jullie reacties. Zoals uit jullie stukjes blijkt, denken jullie dat ik beter gebruik kan maken van een export naar een textfile en dan een import in MySQL via een cronjob. Dit is inmiddels hier binnen het bedrijf ook aan het daglicht gekomen, dus ik denk dat dit een goede oplossing zou kunnen zijn. Helaas staat de MySQL database op een remote server, maar dat betekent dus dat we de beheerders daar op moeten bellen om daar een cronjob aan te maken. Dit is niet zo ernstig, dus daar kunnen we wel mee leven.
De laatste opmerking over dat SQL Server's output niet rechtstreeks MySQL in kan is denk ik waar, het blijft natuurlijk een kopieerslag van een Microsoft-database, dus betaald, naar een Open Source database. Daar zal gewoon wel het knelpunt liggen vanwege de verschillende dialecten SQL en natuurlijk de concurrentie. De foutmelding "Data Overflow" ligt volgens mij namelijk ook bij DTS, dus aan de SQL Server kant, misschien is Microsoft niet zo happig op MySQL (Het kan uiteraard ook anders liggen, maar ik constateer op verschillende punten dat Microsoft-producten toch een beetje een eigen kringetje vormen; Access, ASP, nu SQL Server, Office, etc. Maar hang me er dus niet aan op , het is puur een constatering.)
Ik denk dus dat ACM geen gebrek aan kennis heeft van MSSQL, of tenminste dat ie goed in de gaten heeft waar het probleem zit.
Bedankt voor de reacties, ik heb er zeker wat aan gehad.

Greetz