Hello, Kornel and Wolfgang: These are the parameters of an Oracle Spatial database (actually Oracle Locator) which is publicly available for reading and writing. This DB is not maintained by gvSIG or any company, so it's very unreliable, but maybe we can use it to easily reproduce and fix Oracle-related issues:
URL: lucasdom.homelinux.org Port: 1521 DB name: xe User: gvsig Password: gvsig Obviously, it's extremely slow, so we can only play with tiny layers. Let me know if you have issues with it. In that DB, the fields of the table MINI_ROAD_4326 are very similar to Wolfgang's table: http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20101207/718a9d3d/attachment.jpg Also, the size of the STRAXLON field is 4000, and if I export it to SHP with gvSIG 1.10, the resulting fields are like this, according to ogrinfo: ============================= Geometry: Line String Feature Count: 95 Extent: (14.762572, 55.029009) - (15.027142, 55.157857) Layer SRS WKT: (unknown) ROWID: String (1.0) GID: Real (18.0) OGR_FID: Real (18.0) OBJ_ID: String (7.0) NR: String (8.0) STRANAM: String (254.0) ADR_ZUS: String (1.0) LAND: Real (18.0) REG: Real (18.0) STRASSE: Real (18.0) STRAXLON: String (254.0) STRALON: String (254.0) HOEHE: Real (18.6) ADATE: Date (10.0) ============================= As Wolfgang said, some field types and widths have changed. After fixing that bug, I get this result, which I think is correct, as far as the Oracle driver is concerned. Fields of type String are cropped to 254 characters. I'm not sure if this is a limitation of the DBF format or not, but I have checked that the Oracle driver is providing the metadata correctly: ============================= Geometry: Line String Feature Count: 95 Extent: (14.762572, 55.029009) - (15.027142, 55.157857) Layer SRS WKT: (unknown) ROWID: String (1.0) GID: Real (12.0) OGR_FID: Real (18.0) OBJ_ID: String (7.0) NR: String (8.0) STRANAM: String (254.0) ADR_ZUS: String (1.0) LAND: Integer (2.0) REG: Integer (1.0) STRASSE: Integer (5.0) STRAXLON: String (254.0) STRALON: String (254.0) HOEHE: Real (14.6) ADATE: Date (10.0) ============================= So Kornel: I have not been able to reproduce your problem. Can you somehow create a little table (many columns but very few rows) in that DB exactly like the one that is causing your problems (using SQLDeveloper, gvSIG or other client)? Regards, Juan Lucas Domínguez Rubio --- Prodevelop SL, Valencia (España) Tlf.: 96.351.06.12 -- Fax: 96.351.09.68 http://www.prodevelop.es <http://www.prodevelop.es/> --- ________________________________ De: [email protected] en nombre de K.Kiss Enviado el: mar 14/12/2010 17:00 Para: [email protected] Asunto: Re: [Gvsig_english] Oracle spatial, field length different after exporting to shapefile Hello, I have a similar problem. Briefly described: A Oracle View has originally a field of the type Varchar2 with 4000 byte. If I try into gvSIG (table is loaded and with X/Y - coordinates provide) the table as Shape to export. The presentation was ok. It comes to export errors. 0bytes written >From the memory (the error-entry): "invalid field type 2 (DBF export)" ! If i shorten the Varchar2 to 255 byte, the problem does not exists.... Greetings Kornel Kiss ----- Kornel Kiss Referat für Gesundheit und Umwelt Anforderungsmanagement Fachanwendungen Bayerstr. 28a 80335 München -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Oracle-spatial-field-length-different-after-exporting-to-shapefile-tp5812040p5834434.html Sent from the gvSIG international mailing list archive at Nabble.com. _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
_______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
