On Fri, 2007-09-21 at 11:19 +0200, [EMAIL PROTECTED] wrote: > Hi to all: > > I've the bacula catalog under Postgresql and the database was created > with UTF8 encoding. Now, trying to protect one 'old' client ( REDHAT 3 ) > I get errors from backup job - better said, the errors are raised in the > database - claiming for some characters not valid fro UTF8 encoding, > example > I have found that, despite some documentation and scripts wanting to set things up with UTF8, SQL_ANSI is the only thing that works with postgres. In postgres it just means "take the raw bytes and don't ask questions." I'm running on Linux with postgres 8.1 (no MS Windows involvement).
A later poster remarked that UTF8 can encode any character. While true, that's not the issue. UTF8 provides one way to map from characters to byte-streams; other schemes use other ways. Not all byte streams are valid UTF8, because UTF8 indicates the number of bytes used to encode a character in the upper bits of the first byte. If your stream has a byte that UTF8 interprets to mean "2 more bytes will follow to define this character" and your stream ends sooner than that, UTF8 says you have an error. There may be other kinds of failures possible as well. I don't know exactly what encoding bacula uses for pathnames, or what (if anything) determines the format. But for me, running on Debian, SQL_ANSI was what worked. This seems undesirable; I don't know if it's a bug. I can't evaluate the alternatives you list, but I think any operation that changes the bytes in the database (e.g., telling it to convert from UTF8 to some other format) would be a mistake, since it's not really in UTF8 to begin with. Ross > " > Fatal error: sql_create.c:845 sql_create.c:845 query SELECT FilenameId > FROM Filename WHERE Name='Nenúfares.jpg' failed: > " > > IIUC, here I have three possible ways taking in mind that the > environment to protect could include UTF8 clients, ISO-8859-1, Windows > machines -By now I don't know default enconding, etc... > > > 1.- Recreate catalog using SQL_ASCII ( the environment to protect could > include UTF8 clients, ISO-8859-1, Windows machines -By now I don't know > default enconding, etc... ) > > 2.- May be, forcing character set in the bacula-fd client processes I > get at least a 'buggy chars' but storable in the database ( ? ) ( This > can be accomplished in Oracle at the risk of lose this characters if you > export/import data ) > > 3.- Touch database config to force character set from UTF8 to SQL_ASCII, > but I don't know how Postgresql stores characters and then, I've no > knowledge about implications of this movement. > > > > Based in your experience, and if you have get this issue before, what > should be the correct way? If you know more ways info is wellcome, of > course. > > > Best Regards > > > D. > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
