On Friday 31 July 2009 05:47:39 am Thom Brown wrote:
> Hi all,
>
> We're migrating the contents of an old MSSQL server to PostgreSQL 8.3.7, so
> a full conversion is required. Does anyone know of any guides which
> highlight common gotchas and other userful information?
>
> Thanks
>
> Thom
You mi
On Fri, Jul 31, 2009 at 2:47 PM, Thom Brown wrote:
> Hi all,
>
> We're migrating the contents of an old MSSQL server to PostgreSQL 8.3.7, so
> a full conversion is required. Does anyone know of any guides which
> highlight common gotchas and other userful information?
>
As for other useful inform
On Fri, Jul 31, 2009 at 9:17 AM, Thom Brown wrote:
>
>> That's going to depend a lot on how many features of the database you
>> were using...especially higher level features like stored procedures.
>> Converting the schema and the data shouldn't be too bad -- there are a
>> number of relatively ea
On Fri, 31 Jul 2009 13:47:39 +0100
Thom Brown wrote:
> Hi all,
> We're migrating the contents of an old MSSQL server to PostgreSQL
> 8.3.7, so a full conversion is required. Does anyone know of any
> guides which highlight common gotchas and other userful
> information?
http://wiki.postgresql
> That's going to depend a lot on how many features of the database you
> were using...especially higher level features like stored procedures.
> Converting the schema and the data shouldn't be too bad -- there are a
> number of relatively easy ways to do it including microsoft DTS
> levering the p
On Fri, Jul 31, 2009 at 8:47 AM, Thom Brown wrote:
> Hi all,
>
> We're migrating the contents of an old MSSQL server to PostgreSQL 8.3.7, so
> a full conversion is required. Does anyone know of any guides which
> highlight common gotchas and other userful information?
That's going to depend a lot
Gwyneth Morrison wrote:
Ray,
I think we tried that and I think it works but not for us. It may work
for you.
MS wants to copy all the tables over with exactly the same names
including [dbo]. and so on.
When it doesn't find an exact match, it wants to create the table. This
may be ok for you
Iv Ray wrote:
Hi Ray,
I have something that does this. I am currently awaiting project
approval on pgfoundry.
It does tables, views, and stored procedures. I have tested it on
450,000 lines of mssql code
including 400 tables and 3700 stored procedures, although it is a
work in progress.
I a
Hi Ray,
I have something that does this. I am currently awaiting project
approval on pgfoundry.
It does tables, views, and stored procedures. I have tested it on
450,000 lines of mssql code
including 400 tables and 3700 stored procedures, although it is a work
in progress.
I applied last wee
Iv Ray wrote:
Hello,
what is the current status of the MSSQL to PostgreSQL tools/tips?
Google returns results as old as 2001...
The MSSQL database in question has only tables, no stored procedures,
etc.
Thanks,
Iv
Hi Ray,
I have something that does this. I am currently awaiting project
Tomi NA a écrit :
2006/11/23, Arnaud Lesauvage <[EMAIL PROTECTED]>:
Arnaud Lesauvage a écrit :
> Brandon Aiken a écrit :
>> It also might be a big/little endian problem, although I always thought that
was platform specific, not locale specific.
>>
>> Try the UCS-2-INTERNAL and UCS-4-INTERNAL co
2006/11/23, Arnaud Lesauvage <[EMAIL PROTECTED]>:
Arnaud Lesauvage a écrit :
> Brandon Aiken a écrit :
>> It also might be a big/little endian problem, although I always thought that
was platform specific, not locale specific.
>>
>> Try the UCS-2-INTERNAL and UCS-4-INTERNAL codepages in iconv, w
Arnaud Lesauvage a écrit :
Brandon Aiken a écrit :
It also might be a big/little endian problem, although I always thought that
was platform specific, not locale specific.
Try the UCS-2-INTERNAL and UCS-4-INTERNAL codepages in iconv, which should use
the two-byte or four-byte versions of UCS
Brandon Aiken a écrit :
It also might be a big/little endian problem, although I always thought that
was platform specific, not locale specific.
Try the UCS-2-INTERNAL and UCS-4-INTERNAL codepages in iconv, which should use
the two-byte or four-byte versions of UCS encoding using the system's
On Wed, Nov 22, 2006 at 01:55:55PM -0500, Brandon Aiken wrote:
> Gee, didn't Unicode just so simplify this codepage mess? Remember
> when it was just ASCII, EBCDIC, ANSI, and localized codepages?
I think that's one reason why Unix has standardised on UTF-8 rather
than one of the other Unicode var
2006/11/22, Brandon Aiken <[EMAIL PROTECTED]>:
Gee, didn't Unicode just so simplify this codepage mess? Remember when it was
just ASCII, EBCDIC, ANSI, and localized codepages?
Unicode is a heaven sent, compared to 3 or 4 codepages representing
any given (obviously non-English) language, and
[mailto:[EMAIL PROTECTED] On Behalf Of Arnaud Lesauvage
Sent: Wednesday, November 22, 2006 12:38 PM
To: Arnaud Lesauvage; General
Subject: Re: [GENERAL] MSSQL to PostgreSQL : Encoding problem
Alvaro Herrera a écrit :
> Arnaud Lesauvage wrote:
>> Alvaro Herrera a écrit :
>> >Arnaud Lesa
> > > I thought Win1252 was supposed to be almost the same as Latin1.
> > > While I'd expect certain differences, I wouldn't expect it to use
> > > 0x00 as data!
> > >
> > > Maybe you could have DTS export Unicode, which would
> presumably be
> > > UTF-16, then recode that to something else (
Arnaud Lesauvage wrote:
> > I thought Win1252 was supposed to be almost the same as Latin1. While
> > I'd expect certain differences, I wouldn't expect it to use 0x00 as
> > data!
> >
> > Maybe you could have DTS export Unicode, which would presumably be
> > UTF-16, then recode that to something
Alvaro Herrera a écrit :
Arnaud Lesauvage wrote:
Alvaro Herrera a écrit :
>Arnaud Lesauvage wrote:
>
>>mydb=# SET client_encoding TO LATIN9;
>>SET
>>mydb=# COPY statistiques.detailrecherche (log_gid,
>>champrecherche, valeurrecherche) FROM
>>'E:\\Production\\Temp\\detailrecherche_ansi.csv' CSV
Arnaud Lesauvage wrote:
> Alvaro Herrera a écrit :
> >Arnaud Lesauvage wrote:
> >
> >>mydb=# SET client_encoding TO LATIN9;
> >>SET
> >>mydb=# COPY statistiques.detailrecherche (log_gid,
> >>champrecherche, valeurrecherche) FROM
> >>'E:\\Production\\Temp\\detailrecherche_ansi.csv' CSV;
> >>ERROR:
Arnaud Lesauvage wrote:
> mydb=# SET client_encoding TO LATIN9;
> SET
> mydb=# COPY statistiques.detailrecherche (log_gid,
> champrecherche, valeurrecherche) FROM
> 'E:\\Production\\Temp\\detailrecherche_ansi.csv' CSV;
> ERROR: invalid byte sequence for encoding "LATIN9": 0x00
> HINT: This err
Or go via MS-Access/Perl and ODBC/DBI perhaps?
Yes, I think it would work. The problem is that the DB is too big for
this king of export. Using DTS from MSSQL to export directly to
PostgreSQL using psqlODBC Unicode Driver, I exported ~1000 rows per
second in a 2-columns table with ~20M rows
Alvaro Herrera a écrit :
Arnaud Lesauvage wrote:
Alvaro Herrera a écrit :
>Arnaud Lesauvage wrote:
>>Tomi NA a écrit :
I think I'll go this way... No other choice, actually !
The MSSQL database is in SQL_Latin1_General_CP1_Cl_AS.
I don't really understand what this is. It supports th
Magnus Hagander a écrit :
> I have done this in Delphi using it's built in UTF8 encoding and
> decoding routines. You can get a free copy of Delphi
Turbo Explorer
> which includes components for MS SQL server and ODBC, so it
would be
> pretty straight forward to get this working.
>
> The a
Of course, but it doesn't work !!!
Whatever client encoding I choose in postgresql before COPYing, I get
the 'invalid byte sequence error'.
The farther I can get is exporting to UNICODE and importing as UTF8.
Then COPY only breaks on the euro symbol (otherwise it breaks very
early, I think
Arnaud Lesauvage wrote:
Richard Huxton a écrit :
Or go via MS-Access/Perl and ODBC/DBI perhaps?
Yes, I think it would work. The problem is that the DB is too big for
this king of export. Using DTS from MSSQL to export directly to
PostgreSQL using psqlODBC Unicode Driver, I exported ~1000 ro
Arnaud Lesauvage wrote:
> Alvaro Herrera a écrit :
> >Arnaud Lesauvage wrote:
> >>Tomi NA a écrit :
> I think I'll go this way... No other choice, actually !
> The MSSQL database is in SQL_Latin1_General_CP1_Cl_AS.
> I don't really understand what this is. It supports the euro
> sym
Tomi NA a écrit :
2006/11/21, Arnaud Lesauvage <[EMAIL PROTECTED]>:
Hi list !
I already posted this as "COPY FROM encoding error", but I have
been doing some more tests since then.
I'm trying to export data from MS SQL Server to PostgreSQL.
The tables are quite big (>20M rows), so a CSV export
Alvaro Herrera a écrit :
Arnaud Lesauvage wrote:
Tomi NA a écrit :
>>I think I'll go this way... No other choice, actually !
>>The MSSQL database is in SQL_Latin1_General_CP1_Cl_AS.
>>I don't really understand what this is. It supports the euro
>>symbol, so it is probably not pure LATIN1, right
> >> I already posted this as "COPY FROM encoding error", but I
> have been
> >> doing some more tests since then.
> >>
> >> I'm trying to export data from MS SQL Server to PostgreSQL.
> >> The tables are quite big (>20M rows), so a CSV export and a "COPY
> >> FROM3 import seems to be the only
> > I have done this in Delphi using it's built in UTF8 encoding and
> > decoding routines. You can get a free copy of Delphi
> Turbo Explorer
> > which includes components for MS SQL server and ODBC, so it
> would be
> > pretty straight forward to get this working.
> >
> > The actual meth
2006/11/22, Arnaud Lesauvage <[EMAIL PROTECTED]>:
Tomi NA a écrit :
> 2006/11/21, Arnaud Lesauvage <[EMAIL PROTECTED]>:
>> Hi list !
>>
>> I already posted this as "COPY FROM encoding error", but I have
>> been doing some more tests since then.
>>
>> I'm trying to export data from MS SQL Server t
Arnaud Lesauvage wrote:
> Tomi NA a écrit :
> >>I think I'll go this way... No other choice, actually !
> >>The MSSQL database is in SQL_Latin1_General_CP1_Cl_AS.
> >>I don't really understand what this is. It supports the euro
> >>symbol, so it is probably not pure LATIN1, right ?
> >
> >I suppose
Richard Huxton a écrit :
Arnaud Lesauvage wrote:
Richard Huxton a écrit :
Or go via MS-Access/Perl and ODBC/DBI perhaps?
Yes, I think it would work. The problem is that the DB is too big for
this king of export. Using DTS from MSSQL to export directly to
PostgreSQL using psqlODBC Unicode D
2006/11/21, Arnaud Lesauvage <[EMAIL PROTECTED]>:
Hi list !
I already posted this as "COPY FROM encoding error", but I have
been doing some more tests since then.
I'm trying to export data from MS SQL Server to PostgreSQL.
The tables are quite big (>20M rows), so a CSV export and a "COPY
FROM3
Tomi NA a écrit :
I think I'll go this way... No other choice, actually !
The MSSQL database is in SQL_Latin1_General_CP1_Cl_AS.
I don't really understand what this is. It supports the euro
symbol, so it is probably not pure LATIN1, right ?
I suppose you'd have to look at the latin1 codepage ch
Richard Huxton a écrit :
Arnaud Lesauvage wrote:
Hi list !
I already posted this as "COPY FROM encoding error", but I have been
doing some more tests since then.
I'm trying to export data from MS SQL Server to PostgreSQL.
The tables are quite big (>20M rows), so a CSV export and a "COPY FROM
Tony Caduto wrote:
Arnaud Lesauvage wrote:
I then try to import into PostgreSQL. The farther I can get is when
using the UNICODE export, and importing it using a client_encoding
set to UTF8 (I tried WIN1252, LATIN9, LATIN1, ...).
The copy then stops with an error :
ERROR: invalid byte seque
Arnaud Lesauvage wrote:
I then try to import into PostgreSQL. The farther I can get is when
using the UNICODE export, and importing it using a client_encoding
set to UTF8 (I tried WIN1252, LATIN9, LATIN1, ...).
The copy then stops with an error :
ERROR: invalid byte sequence for encoding "UT
40 matches
Mail list logo
