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

--

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
>
> --
>

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

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

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

--

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

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

--

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

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
--