Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
CDCollector - Unicode |
Fri, Oct 24 2008 10:34 AM | Permanent Link |
"Malcolm" | EDB 2.02b2 unicode
D2009 Just diping toe in the water .. brrrrr! Having seen so many exhortations to study CDCollector I thought it would be a good idea to start there. Carefully opened the unicode version in IDE, had a wee gander, then tried to build. Just one hint - to use CharInSet. Used CharInSet and re-built with no errors, warnings or hints. Looking good. Then ran it .. woops! the table components all use TStringField for the VARCHAR fields so a bunch of type errors and tables failed to open. Double-check, have I opened the unicode version .. yup. Is this just a mater of Tim 'getting a round tuit' or have I missed something? Is this just a straight copy of the Ansi version which I need to massage? Malcolm -- |
Fri, Oct 24 2008 1:08 PM | Permanent Link |
Lance Rasmussen Jazzie Software Team Elevate | If it compiles......... ship it.... 8v]
Probably an oversight I'm sure... Lance "Malcolm" <malcolm@spam.will.bounce> wrote in message news:BD88E455-51AF-4025-9C2B-5442B5607C0B@news.elevatesoft.com... > EDB 2.02b2 unicode > D2009 > > Just diping toe in the water .. brrrrr! > > Having seen so many exhortations to study CDCollector > I thought it would be a good idea to start there. > > Carefully opened the unicode version in IDE, had a wee > gander, then tried to build. Just one hint - to use CharInSet. > Used CharInSet and re-built with no errors, warnings > or hints. Looking good. > > Then ran it .. woops! the table components all use > TStringField for the VARCHAR fields so a bunch of > type errors and tables failed to open. > > Double-check, have I opened the unicode version .. yup. > > Is this just a mater of Tim 'getting a round tuit' or > have I missed something? Is this just a straight copy > of the Ansi version which I need to massage? > > Malcolm > > -- > |
Fri, Oct 24 2008 1:16 PM | Permanent Link |
"Malcolm" | Lance Rasmussen [Team Elevate] wrote:
> If it compiles......... ship it.... 8v] > > Probably an oversight I'm sure... > > Lance > Well, after wide-ning all TStringFields, it runs fine. But I am puzzled why that was necessary.. ... something to do with the components? Will this be necessary every time an EDBTable is needed on a form/module? Malcolm |
Fri, Oct 24 2008 7:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Malcolm,
<< Well, after wide-ning all TStringFields, it runs fine. But I am puzzled why that was necessary.. .. something to do with the components? >> No, it was just an oversight that was left in there due to the copy of the ANSI version. I will make sure that it is corrected for the next build. << Will this be necessary every time an EDBTable is needed on a form/module? >> No, any time you use the Unicode version it will automatically create all persistent (and non-persistent) string fields as TWideStringField objects. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Oct 25 2008 4:15 AM | Permanent Link |
"Malcolm" | Tim Young [Elevate Software] wrote:
> Malcolm, > > << Well, after wide-ning all TStringFields, it runs fine. But I am puzzled why that was necessary.. .. something to do with the components? >> > > No, it was just an oversight that was left in there due to the copy of the ANSI version. I will make sure that it is corrected for the next build. Thanks. > > << Will this be necessary every time an EDBTable is needed on a form/module? >> > > No, any time you use the Unicode version it will automatically create all persistent (and non-persistent) string fields as TWideStringField objects. OK, I believe you - I did drop a new Table component on the data module and added a string field as a quick test but it too came up as a T<narrow>StringField. I suspect it was an improper test! Don't worry unless I get back here... Malcolm -- |
Mon, Oct 27 2008 1:41 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Malcolm,
<< OK, I believe you - I did drop a new Table component on the data module and added a string field as a quick test but it too came up as a T<narrow>StringField. I suspect it was an improper test! >> Are you sure that you're using the Unicode version of the EDB design-time package ? The only way that a CHAR/VARCHAR column would appear as a persistent TStringField is if you're using the ANSI version of the EDB design-time package. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Oct 27 2008 7:39 PM | Permanent Link |
"Malcolm" | Tim Young [Elevate Software] wrote:
> > Are you sure that you're using the Unicode version of the EDB design-time package ? The only way that a CHAR/VARCHAR column would appear as a persistent TStringField is if you're using the ANSI version of the EDB design-time package. As I said, it may have been an invalid test. I downloaded only the Unicode version and it has installed with 'unicode' in the foldernames. Ignore this unless I come back later. Malcolm -- |
Wed, Oct 29 2008 1:30 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Malcolm,
<< As I said, it may have been an invalid test. I downloaded only the Unicode version and it has installed with 'unicode' in the foldernames. Ignore this unless I come back later. >> Actually, I think I know where the issue is. If the FieldDefs for the TEDB* component were already populated and saved as part of the form, then creating any persistent fields would result in the new TField components using the existing FieldDefs, and thus using ftString as the data type instead of ftWideString. Clearing the FieldDefs and persistent TFields, and then re-populating the persistent TFields using the Fields Editor, should do the trick in correcting this. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Oct 29 2008 6:44 PM | Permanent Link |
"Malcolm" | Tim Young [Elevate Software] wrote:
> > Actually, I think I know where the issue is. If the FieldDefs for the TEDB* component were already populated and saved as part of the form, then creating any persistent fields would result in the new TField components using the existing FieldDefs, and thus using ftString as the data type instead of ftWideString. Clearing the FieldDefs and persistent TFields, and then re-populating the persistent TFields using the Fields Editor, should do the trick in correcting this. Been sidetracked .. I am sure you will be right. Ta! Malcolm -- |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |