ODBC naar MSSQL: dump werkt niet goed


#1

Hallo,

Ik probeer met foondump 4.10a, CDFOON ZK2004-3 te dumpen naar Microsoft SQLServer. Ik heb de tables handmatig opgebouwd in MSSQL adhv het MySQL script. Ik krijg onderstaande meldingen, en geen enkel record wordt gedumpt.

Doe ik iets fout? De foutmeldingen zijn voor mij enigzins cryptisch…

Overigens, dumpen naar bijv. CSV file geeft geen problemen.

Alvast bedankt!

[color=blue]D)irectory: [c:\cdfoon_cd] (Gevonden: versie ZM3.2004)

Dumpen naar: [ ] B)estand (eenvoudig) [ ] CSV) Bestand
[ ] F)oonsearch CSV Bestand [ ] M)ySQL database
[ ] PostgreSQL dA)tabase [o] O)DBC database

Dumpen van gids: [x] W)it (personen) [ ] J) Maak indextabellen
(Y=Alle opties) [ ] Wit FaX)/mobiel
[ ] Wit I)nfo
[ ] R)oze (bedrijven)
[ ] Roze fax/mobieL)
[ ] RoZ)e info
[ ] Geografische data: postcodes met C)oordinaten
[ ] K)aartsegmenten en -coordinaten

Database U)ser: [beheerder]
Database P)ass: [password]
Database N)ame: [dbnl]

S)tart dumpen

Maak je keuze door op de juiste letter te drukken, gevolgd door .
s

CDFoonGids versie ZM3.2004
Data directory: C:\cdfoon_cd\data

[00:00:00] Bezig met dumpen van Aadorp (684 namen)
java.lang.ArrayIndexOutOfBoundsException
at sun.jdbc.odbc.JdbcOdbcPreparedStatement.execute(JdbcOdbcPreparedState
ment.java:256)
at sun.jdbc.odbc.JdbcOdbcPreparedStatement.executeBatchUpdate(JdbcOdbcPr
eparedStatement.java:1471)
at sun.jdbc.odbc.JdbcOdbcStatement.executeBatch(JdbcOdbcStatement.java:8
81)
at nl.foondump.WhiteDumper.flushBuffers(WhiteDumper.java:341)
at nl.foondump.WhiteDumper.doDump(WhiteDumper.java:140)
at com.kpn.cdfoon.app.FoonDump.(FoonDump.java:90)
at com.kpn.cdfoon.app.FoonDump.main(FoonDump.java:514)

C:\cdfoon_foondump>[/color]


#2

Bij mij wil het ook nog niet.
Na een eerste foutmelding “java.lang.NegativeArraySizeException” Foondump opnieuw gestart.
Dan loopt ie en nog heel erg snel ook:

... [00:25:15] Bezig met dumpen van Zwijndrecht (7454 namen) [00:25:18] Bezig met dumpen van Zwinderen (309 namen) [00:25:18] Bezig met dumpen van Zwolle (16759 namen) Klaar met dumpen Witte deel.
Te snel, in die 25 minuten en 18 seconden werd er alleen naar ‘metadata’ geschreven, de rest bleef leeg:

[C:\Foondump\2004\Test mssql]db -d Foondump2004 "SELECT * FROM fd_metadata" metaname metavalue white_complete yes white_version ZM4.2004 white_lastcity white_lastname pink_complete no pink_version ZM4.2004
Overigens lijkt de tijd die Foondump nu nodig had om door de hele lijst te lopen op de tijd die Megafoon nodig had om de hele CD te exporteren.

Jij zegt, dumpen naar CSV gaf geen problemen.
Dat betrof de direct-naar-CSV optie van Foondump?

Dumpen naar CSV via ODBC heb ik namelijk ook uitgeprobeerd…
Schema.ini gemaakt en een batch bestandje om lege csv’s aan te maken.
No joy, Foondump gaf een SQLException voor de[Microsoft][ODBC Text Driver]:
"… cannot open the file ‘(unknown)’. It is already opened exclusively by another user, or you need permission …"
Zelf nog een stukje Java geknutseld waarmee het wel lukte om bijvoorbeeld via die tekst-DSN naar de tabel ‘metadata’ te schrijven.
Het daarna maar opgegeven.


#3

Hoi raynl2000, Rotkapje,

Problemen waar ik wel eens van heb gehoord/gezien:

  1. driver. Lijkt mij geen probleem wat je gebruikt standaard.

  2. reserved words. Zou je direct moeten zien bij het laden van de tabellen.

  3. tabellen niet goed gedefineerd. Zou best kunnen. Mogelijk een paar (foondump) record proberen in te voegen. Worden onderwater geen records gemaakt in foondump?

  4. Zijn alle ODBC commando’s wel geimplementeerd in MSSQL. Ik weet dat je vaak een “load table” doet of dat je veel record invoegt met een “commit” om ze in 1 keer echt te laten invoegen. Ik denk dus aan Batch inserting o.i.d.

De vriendelijke groet Jan Marco


#4

Hallo Jan Marco,

Bedankt voor je antwoord. Ik zou graag e.e.a. uitzoeken voor MSSQL en m’n bevindingen ook plaatsen hier, probleem is alleen dat ik niet weet waar ik zou moeten beginnen omdat de foutmeldingen me weinig zeggen. Wat ze me zeggen is dat het met java te maken heeft (als ik het goed begrepen heb, waarin foondump geschreven is).

Bijvoorbeeld de eerste melding:

java.lang.ArrayIndexOutOfBoundsException

Het enige wat mij dit zegt (en dat kan natuurlijk helemaal fout zijn) is dat er een bug in foondump zit, omdat een array verkeerd gevuld wordt (index out of bound betekent voor mij dat je bijvoorbeeld een 11e element in een array van 10 groot probeert te stoppen).

Nu zou het best zo kunnen zijn dat dit niet zozeer een bug is, als wel het gevolg van een verkeerd ingericht MSSQL database… maar er is helemaal geen informatie voorhanden wát dan fout is.

Zoals ik al zei, de table layout heb ik gekopieerd van de MySQL query. Hier is de MSSQL script:

[quote]CREATE TABLE [dbo].[fd_metadata] (
[metaname] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[metavalue] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [primary]
GO

CREATE TABLE [dbo].[fs_town_street] (
[townname] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[streetname] [varchar] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[fs_towns] (
[townname] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[gis_gifinfo] (
[seqno] [int] NOT NULL ,
[scale] [int] NOT NULL ,
[x_low] [int] NOT NULL ,
[y_low] [int] NOT NULL ,
[x_hi] [int] NOT NULL ,
[y_hi] [int] NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[gis_postalcoords] (
[id] [int] NOT NULL ,
[postalcode] [varchar] (6) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[rd_x] [int] NOT NULL ,
[rd_y] [int] NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[pink_categories] (
[catid] [int] NOT NULL ,
[category] [varchar] (96) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[pink_info] (
[id] [int] NOT NULL ,
[lineno] [int] NOT NULL ,
[recno] [int] NOT NULL ,
[type] [int] NULL ,
[infovalue] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [primary]
GO

CREATE TABLE [dbo].[pink_phonenumbers] (
[id] [int] NOT NULL ,
[phonenumber] [varchar] (24) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[type] [int] NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[pink_subscriber] (
[id] [int] NOT NULL ,
[fullname] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[streetname] [varchar] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[streetnameextension] [varchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[housenumber] [varchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[housenumberextension] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[residence] [char] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[postalcode] [varchar] (9) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[townname] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[areacode] [varchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[subscribernumber] [varchar] (16) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [primary]
GO

CREATE TABLE [dbo].[pink_subscribercategories] (
[catid] [int] NOT NULL ,
[subid] [int] NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[pink_unique] (
[md5] [char] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[id] [int] NULL
) ON [primary]
GO

CREATE TABLE [dbo].[white_info] (
[id] [int] NOT NULL ,
[lineno] [int] NOT NULL ,
[recno] [int] NOT NULL ,
[type] [int] NULL ,
[infovalue] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [primary]
GO

CREATE TABLE [dbo].[white_phonenumbers] (
[id] [int] NOT NULL ,
[phonenumber] [varchar] (24) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[type] [int] NOT NULL
) ON [primary]
GO

CREATE TABLE [dbo].[white_subscriber] (
[seq] [int] IDENTITY (1, 1) NOT NULL ,
[id] [int] NULL ,
[lastname] [varchar] (128) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[fullname] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[streetname] [varchar] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[streetnameextension] [varchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[housenumber] [varchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[housenumberextension] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[residence] [char] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[postalcode] [varchar] (9) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[townname] [varchar] (32) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[areacode] [varchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[subscribernumber] [varchar] (16) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [primary]
GO[/quote]


#5

Hoi Jan Marco, raynl2000

Mee eens, het blijft wegstrepen van mogelijke oorzaken, wat dat aangaat:
andere ODBC-handelingen zoals overzetten van de ODBC-dump-naar-Access vanuit Access zelf geven bij mij geen problemen. Kan je zeggen dat is MS inteelt maar met alternatieve ODBC-spullen als Chyfo of de 'db-utility van MKS kan ik ook terecht in mijn mssql-tabellen voor Foondump.

Je kan een beetje varieren, bijv. als ik raynl2000’s definities gebruik hou ik mijn eigen exception maar ik krijg dan niet meer mijn “Foondump-topsnelheids-dump”-verschijnsel.

Wat raynl2000 zegt het probleem blijft inderdaad dat er heel veel informatie te vinden is voor ODBC/MSSQL en niet over de interne werking van Foondump.


#6

Hoi raynl2000, Rotkapje,

Wat raynl2000 zegt het probleem blijft inderdaad dat er heel veel informatie te vinden is voor ODBC/MSSQL en niet over de interne werking van Foondump.

M.i. is de werking opzich niet al te spannend. Men bouwt in java sql queries op die via een JDBC/ODBC koppeling aangeboden worden aan een (ODBC) database.

Ik zie bijvoorbeeld:
“insert into white_subscriber (id, lastname, fullname, streetname, streetnameextension, housenumber, housenumberextension, residence, postalcode, townname, areacode, subscribernumber) values (?,?,?,?,?, ?,?,?,?,?, ?,?);”

M.i. zijn er twee oplossingsrichtingen.

  1. We gaan voorbeeld ingevulde test jdbc java sql statements maken welke getest kunnen worden voor de verschillende database pakketen.

Bijvoorbeeld de vraagtekenjes ingevuld in bovenstaande SQL statement.

Als je een bepaalde database gaat aankoppelen kan je deze gebruiken om te testen of de database pakket werkt.

  1. Je vraagt een kopie van de java source aan rgj en je gaat zelf experimenteren met de code i.r.t MSSQL.

De vriendelijke groet Jan Marco


#7

Jan Marco, sneu om te horen dat het onderwerp aan glans heeft verloren voor je :o) Dat is wel eens anders geweest:

[quote="alkema_jm also "]A number of factors influence choosing the ODBC approach. These include a requirement for high performance, more granular control over the interface, and a small footprint.

If your application requires very fast access to existing ODBC data, and you’re willing to write many lines of complex code (or you already have a lot of ODBC code available for reuse), ODBC is a good choice.

forums.virtualconspiracy.com/foondump/viewtopic.php?p=228#228[/quote]


#8

Hoi Weerman,

Jan Marco, sneu om te horen dat het onderwerp aan glans heeft verloren voor je :o) Dat is wel eens anders geweest:

JDBC/ODBC is wel een goede interface om databases aan te koppelen. In megafoon hebben we bijvoorbeeld ook de ODBC koppeling er in gemaakt.

Wel heel interessant, maar niet spannend meer:

Ben nu erg met threads/semaphoren bezig. Begin het een beetje te begrijpen. Ik ga van het weekend proberen om de RSA encrypty in testgnunetd werkend te krijgen. Ik vind het altijd leuk om dingen uit te zoeken die in nog niet zo goed ken.

De vriendelijke groet Jan Marco


#9

Inderdaad duidt de ArrayIndexOufOfBounds exception vanuit Whitedumper regel 341 op een probleem met het aantal kolommen in je database.
Echter, je database definitie lijkt goed te zijn. Ik weet het dus ook even niet.

Het ‘snelle dumpen’: ik vermoed dat de code er tijdens de eerste ‘flushBuffers’ in elke stad uit vliegt, zonder melding. Dat wil zeggen dat van elke stad slechts de eerste 1000 records worden opgehaald.


#10

Hoi raynl2000, RGJ,

Ik denk dat mssql een belangrijke database is om foondump in te kunnen laten dumpen --)

Hebben jullie al een idee hoe het puzzeltje opgelost kan worden?

Zelf denk ik aan of het mogelijk is om bij RGJ of mij te dumpen en de records te laten ‘ontvangen’ bij raynl2000 via een internetlink. Mogelijk zie je in java runtime het probleem.

De vriendelijke groet Jan Marco


#11

Via een omweg langs mysql krijg je een dump ook wel in sqlserver.

Alleen jammer als de “universele” ODBC-optie er toch niet zou komen vanwege iets kleins. Als ik “proficient” in Java was kon je mij rustig als vrijwilliger aanwijzen om het uit te zoeken. Kan het evengoed wel proberen, de code lezen zal wel lukken, maar iemand die vaker met dat bijltje gehakt heeft (zoals een van jullie beiden) komt er misschien sneller uit, zeg het maar.

Tot die tijd kan ik wel vanaf de zijlijn helpen, ik zie dat anderen ook melding maken van “mijn” exception (NegativeArraySizeException) als ze met Java naar sqlserver willen:

Usenet:
http://groups.google.nl/groups?hl=nl&lr=&th=211d29abcb57a744&rnum=3][u]comp.lang.java.databases[/u

Halverwege die discussie komt iemand met een
http://groups.google.nl/groups?selm=3A01D76A.5749C49F%40weblogic.com&output=gplain][u]work-around[/u

In een forum bij Sun, eveneens al wat langer geleden:
http://forum.java.sun.com/thread.jspa?forumID=48&messageID=232617&threadID=89700][u]Java Database Connectivity (JDBC) & Transactions (JTA/JTS)[/u

Misschien gaat het probleem vanzelf weg als jullie separaat de vrij beschikbare
http://www.microsoft.com/downloads/details.aspx?FamilyID=9f1874b6-f8e1-4bd6-947c-0fc5bf05bf71&displaylang=en][u]Microsoft SQL Server 2000 JDBC Driver[/u
inzetten?
Dus net zoals het in de Foondump-download voor Postgres gedaan is?

Dan niet de Windows-versie nemen maar de pure Java driver die in de mssqlserver.tar voor Solaris zit zeggen ze
http://www.akadia.com/services/sqlsrv_jdbc.html][u]hier[/u


#12

Ik stel mijn mssql graag ter beschikking via een internetlink. Ik heb kabel dus met de snelheid zit het wel ok. Dus zeg maar wat ik moet doen en dat komt voor elkaar.

Met Java zelf heb ik geen enkele ervaring, dus daar kan ik waarschijnlijk niet mee helpen.

Ik ben op dit moment bezig om de gegevens via een “platte” textfile naar mssql te krijgen. Een omweg, en veel data wordt niet beschikbaar, maar het is een begin. Zodra het af is zal ik het hier posten voor anderen die het evt. willen gebruiken.

Bedankt!