Обсуждение: pgSchema Changes
Hi Jean-Michel, I just comitted the following changes to pgSchema: Invalidate Caches before refreshing hierarchy in pgSchema. Standardised db name access method throughout pgSchema's classes, and added caching. This update touched virtually all classes and is quite large, but shouldn't affect anything you're doing. Note that the correct method for accessing the parent db name within a class is now through the 'Database' property, *not* using GetDatabase e.g: objServer.Databases(Database).KillCommentCache Cheers, Dave.
Hi Dave, I used pgSchema today with a Latin1 encoding hack. Whenever a character does not exist in Latin1 (example : euro sign), an error is returned. Obviously, this is not always the case: Japanese is transformed in unreadable characters without error. My impression is that client encoding is not ***very** secure. A full unicode chain is a better solution. But we need Client encoding support as it offers a wide variety of encodings ... and is compatible with VB. Maybe we could start modifying pgSchema->Databases and pgSchema->pgDatabase. What would you think if we : - renamed EncodingName into ServerEncoding, - added ClientEncoding. Then, in frmSQLInput, we would add a combo to choose the encoding needed. This will allow me to view UTF-8 data in Latin1 and export it in UTF-8. Isn't it marvelous? Cheers, Jean-Michel
Hi Dave, Also, we need to set Schema->Encoding. This is to define what client encoding is used for schema creation. For example, I would like to use Latin1 for writing functions. Cheers, Jean-Michel
Jean-Michel POURE allegedly said: > Hi Dave, > > I used pgSchema today with a Latin1 encoding hack. > > Whenever a character does not exist in Latin1 (example : euro sign), an > error is returned. Obviously, this is not always the case: Japanese is > transformed in unreadable characters without error. > > My impression is that client encoding is not ***very** secure. A full > unicode chain is a better solution. But we need Client encoding > support as it offers a wide variety of encodings ... and is compatible > with VB. > > Maybe we could start modifying pgSchema->Databases and > pgSchema->pgDatabase. What would you think if we : > - renamed EncodingName into ServerEncoding, > - added ClientEncoding. We currently have: Encoding (Long) EncodingName (String) Maybe change these to: ServerEncodingID (Long) ServerEncodingName (String) and add: ClientEncodingID (Long) ClientEncodingName (String) The ClientEncodingID would be the Windows LCID (I assume that's relevant in this case) > > Then, in frmSQLInput, we would add a combo to choose the encoding > needed. I'm not sure that's the best place. It would need to be somewhere that's relevant to the whole connection, because that's how it would be set. What about setting it from the Context menu (right click), and the database properties page. We could then remember the encoding per database in the registry for future connections. > This will allow me to view UTF-8 data in Latin1 and export it in UTF-8. > Isn't it marvelous? It will be when it works :-) Regards, Dave.
Jean-Michel POURE allegedly said: > Hi Dave, > > Also, we need to set Schema->Encoding. This is to define what client > encoding is used for schema creation. For example, I would like to use > Latin1 for writing functions. As I said in my previous message, we can only set it once for each database, otherwise it will become unpredictable as you jump from window to window. The only other option I can think of, would be to open a dedicated connection for each SQL window, but this would: a) waste resources. b) bypass logging, query recording etc. in pgSchema (definately not acceptable). Regards, Dave.
Hi Dave,
1) We need two client encodings :
- one for querying system object,
- another for displaying data.
> DataEncodingID (Long)
> DataEncodingName (String)
The encoding used to display data.
In my example, UTF-8 to export data, Latin1 otherwize.
> SystemEncodingID (Long)
> SystemEncodingName (String)
The encoding used to program schema objects, in my case Latin1.
"System" because this term is used in pgServerExecSQL.
Example : my database is UTF-8:
- Latin1 objects,
- Japanese data.
2) I hacked pgServerExecSQL like this :
>As I said in my previous message, we can only set it once for each
database, otherwise it will become unpredictable as you jump from window
to window.
'Get the Query Type and set client encoding
szClientEncoding = "SQL_ASCII"
SQL_Encoding = ""
If (QryType And qrySystem) = qrySystem Then
szQueryType = "System"
szClientEncoding = objServer.Databases(Database).SystemEncodingName
ElseIf (QryType And qryData) = qryData Then
szQueryType = "Data"
szClientEncoding = objServer.Databases(Database).DataEncodingName
ElseIf (QryType And qryUser) = qryUser Then
szQueryType = "User"
szClientEncoding = "SQL_ASCII"
End If
If szClientEncoding <> "" Then
SQL_Encoding = "SET CLIENT_ENCODING = '" & szClientEncoding & "'; "
End If
RaiseEvent SQLExecute(SQL, Connection)
objServer.iLogEvent "SQL (" & GetDatabase(Connection.ConnectionString) &
"): " & SQL, etSQL
Set ExecSQL = Connection.Execute(SQL_Encoding & SQL)
What do you think?
Le Lundi 25 Février 2002 21:30, Dave Page a écrit : > As I said in my previous message, we can only set it once for each > database, otherwise it will become unpredictable as you jump from window > to window. > The only other option I can think of, would be to open a dedicated > connection for each SQL window, but this would: > a) waste resources. > b) bypass logging, query recording etc. in pgSchema (definately not > acceptable). OK, let's go for your solution.
> ServerEncodingID (Long) > ServerEncodingName (String) I still wonder why ServerEncodingID is needed. It adds complexity to pgSchema without beeing used. Can't ServerEncodingID be masked? > ClientEncodingID (Long) > The ClientEncodingID would be the Windows LCID (I assume that's relevant > in this case) To you plan to use ClientEncodingID to select fonts? What is LCID for? My knowledge is very little in this field. Cheers, Jean-Michel