![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 5 of 5 total |
![]() |
Mon, Feb 10 2014 2:42 PM | Permanent Link |
Tiago Ameller Menorca Zeros i Uns SL | I'm migrating my servers from 2.10 to 2.15 and having troubles with ANSI/UNICODE. And have a lot of questions
![]() The configuration.modules table has field "CharacterSet" set to NULL with my modules, where migrator modules provided by EDB are filled with 'ANSI'. CREATE MODULE clause has no parameter to inform character set. I guess EDB detect this at registering modules, isn't it? My modules weren't working well until I changed EDBExternalModuleRoutine(const RoutineName: EDBString); for a single String const parameter. This has had a cost of two hours to find it (no compile errors, no runtime errors, just NULL return values ...) My databases are ANSI, EDBServer is configured as ANSI, client applications are compiled with EDB ANSI components, EDBManager and my apps sessions are configured as ANSI ... When I'll send to production will work all right? To convert my ANSI world to a UNICODE world, how to migrate databases? will databases increase their size? Thanks! Tiago Ameller Menorca Zeros i Uns SL www.sistemasc.net |
Tue, Feb 11 2014 9:50 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Tiago,
<< CREATE MODULE clause has no parameter to inform character set. I guess EDB detect this at registering modules, isn't it? >> No, it's read from the actual module itself via a function call. The character set is derived from a compiler define, but there's a bug in 2.15 related to that. << My modules weren't working well until I changed EDBExternalModuleRoutine(const RoutineName: EDBString); for a single String const parameter. This has had a cost of two hours to find it (no compile errors, no runtime errors, just NULL return values ...) >> Which unit are you referring to ? Your module's main unit ? If you're using AnsiStrings all-around (including Delphi's default string type), then TEDBString=AnsiString, so there should not be any difference in operation. << My databases are ANSI, EDBServer is configured as ANSI, client applications are compiled with EDB ANSI components, EDBManager and my apps sessions are configured as ANSI ... When I'll send to production will work all right? >> Yes, you will be okay with that configuration. The bug mentioned above is only an issue when trying to compile Unicode modules. However, you should wait to deploy until we clear up the above issue, since I'm not sure what the issue was there. << To convert my ANSI world to a UNICODE world, how to migrate databases? will databases increase their size? >> I'll be adding an ANSI/Unicode migrator (both directions) shortly, so you should wait until they are available. It will be a lot easier than what you have to do right now. And yes, it will increase their size. Tim Young Elevate Software www.elevatesoft.com |
Tue, Feb 11 2014 12:50 PM | Permanent Link |
Tiago Ameller Menorca Zeros i Uns SL | Tim,
<<Which unit are you referring to ? Your module's main unit ? If you're using AnsiStrings all-around (including Delphi's default string type), then TEDBString=AnsiString, so there should not be any difference in operation.>> My external modules where created with earlier versions of EDB. I realize after migrating to 2.15 I must change all TEDBString for just String. Some errors were at compile time, others not. type Tm01BurocraticaModule = class(TEDBExternalModule) procedure EDBExternalModuleRoutine(const RoutineName: string); // <- here was TEDBString end; procedure Tm01BurocraticaModule.EDBExternalModuleRoutine(const RoutineName: string); begin if SameText(RoutineName,'NombreCompleto') then // erratic matches here. Of course, no compile/runtime error ... Now it's all working with server and client running 2.15b3 IMHO most of we, local near-to-customer developers, don't need Unicode. It's an unwanted hassle. ANSI is enough for my customers and keep database size small is important. Tiago Ameller Menorca Zeros i Uns SL www.sistemasc.net |
Wed, Feb 12 2014 9:13 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Tiago,
<< IMHO most of we, local near-to-customer developers, don't need Unicode. It's an unwanted hassle. ANSI is enough for my customers and keep database size small is important. >> You might change your mind if you were Japanese. ![]() Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 12 2014 12:03 PM | Permanent Link |
Tiago Ameller Menorca Zeros i Uns SL | Tim,
<<You might change your mind if you were Japanese. ![]() Of course! But all Spanish, Catalan and near languages and signs are fortunately supported by ANSI ![]() Tim Young Elevate Software www.elevatesoft.com Tiago Ameller Menorca Zeros i Uns SL www.sistemasc.net |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |