XXX is not of the expected type.
where XX is the name of a memofield, declared Memo
in Paradox and Text in MSSQL (I converted with the Datapump)
I cant see any difference between these two TFields,
can anyone help me with this?
I really want it to be swappable Paradox/MSSQL,
so I dont need to have two versions,
or am I too optimistic?
Thanks,
Jan Ramströmer
The TField is giving you the error.
If you don't need the persistent TFields, you can drop them and have the
TDBMemo hooked to the field (Pdox and MSSQL) without the TFields stored in
the table. At run time when you open the table the TFields will be created
and the FieldType should be assigned correctly.
Try it in a little sample project first but I think it will work.
Matthew
Jan Ramströmer wrote in message <01bd6ab3$542bf8a0$77a4f482@default>...
but I really need the persistent TFields,
(display formatting, validations etc)
I have tried to drop them, and it works fine, I know.
I wonder what is causing the error message. It must be some
TField property that is assigned wrong.
(Not the datatype, I've checked that)
If I found out which property, maybe I can change it before
opening the table.
Any ideas?
Matthew McDermott <N.O.S.P.A...@acpm.edu> skrev i inlägg
<6habcc$d3...@forums.borland.com>...
I'm having a similar problem reading Dbase files & sending them to SQL
Anywhere. Only mine seems to be machine specific. The TField is pulled in
as TSmallInt on my development machine, and as TFloat on my laptop. At the
client site, some machines see it as TSmallInt, some as TFloat. BDE, ODBC,
etc. are all the same versions w/the same settings. I'm beginning to
strongly suspect some sort of difference at a hardware level (different
Pentium problems? Is this related to the F00F problem?), or to something
in BDE or ODBC under the covers. Unfortunately, I have found no solution.
I hope you have better luck.
Cheers,
Cyd
> I cant see any difference between these two TFields,
> can anyone help me with this?
We ran into this when we converted from Paradox to MS SQL. The
TMemoField SIZE property changes. I think this happens to any
TBlobField descendent.
I suggest you write a BeforeOpen event. Call FieldDefs.Update, then
iterate over the Fields array and "patch" any TBlobField size values
that are incorrect.
> I really want it to be swappable Paradox/MSSQL,
> so I dont need to have two versions,
> or am I too optimistic?
It's probably not a realistic goal unless it's a pretty small
application. You'll start running into many more differences between
the way Paradox and SQL server do things, like indexes and lock
records.
ODBC? You should not be needing ODBC for a dBase file.
I check the BDE driver and alias settings VERY carefully. I'd ask
someone to look with a "new set of eyes" because I sometimes see what I
expect to see. Don't forget to check check the
Configuration/Drivers/Native/Dbase tab, particularly the LEVEL. Also
check ENABLE BCD in the database alias, although I would not expect
that to matter.
convert(num(10,2),theVar)
...and Delphi complained about it. I removed the (10,2) and it worked fine.
Juan
Jan Ramströmer wrote in message <01bd6b14$ffdc7d80$68cff482@default>...
>> >I cant see any difference between these two TFields,
>> >can anyone help me with this?
>> >
>> >I really want it to be swappable Paradox/MSSQL,
>> >so I dont need to have two versions,
>> >or am I too optimistic?
>> >
>> >Thanks,
>> >Jan Ramströmer
>>
>>
>>
I will try your idea with the size property.
Probably I will drop my Paradox plans, but I really need it to be
swappable MSSQL/SQL Anywhere.
Do you think this is optimistic too?
/Jan Ramströmer
Scott Samet <sp...@me.not> skrev i inlägg <VA.0000001f.0489c15b@keywest>...
> In article <01bd6ab3$542bf8a0$77a4f482@default>, Jan Ramströmer wrote:
>
> > I cant see any difference between these two TFields,
> > can anyone help me with this?
>
> We ran into this when we converted from Paradox to MS SQL. The
> TMemoField SIZE property changes. I think this happens to any
> TBlobField descendent.
>
> I suggest you write a BeforeOpen event. Call FieldDefs.Update, then
> iterate over the Fields array and "patch" any TBlobField size values
> that are incorrect.
>
> > I really want it to be swappable Paradox/MSSQL,
> > so I dont need to have two versions,
> > or am I too optimistic?
>
If you want this to work, put the Open statement in a try..except block and
change the fieldtype in case of an exception.
Thomas Werner
Å-DATA AB
Jan Ramströmer skrev i meddelandet <01bd6ab3$542bf8a0$77a4f482@default>...
>I am trying to upsize my application from Paradox
>to MSSQL, and I have encountered a strange problem.
>I created persistent TFields using Paradox tables,
>and everything works fine. If I delete these TFields
>and recreate them using MSSQL everything works fine too.
>But when I create them using Paradox and change
>to MSSQL during execution I get the message:
>
> XXX is not of the expected type.
>
>where XX is the name of a memofield, declared Memo
>in Paradox and Text in MSSQL (I converted with the Datapump)
>I cant see any difference between these two TFields,
>can anyone help me with this?
>
>I really want it to be swappable Paradox/MSSQL,
>so I dont need to have two versions,
>or am I too optimistic?
>
>Thanks,
>Jan Ramströmer
we had the same problem when porting an application from Paradox to MSSQL.
Now we do exactly what Scott has recommended to do. The size of TMemos even
changes from SQL Links version to SQL links version. So be sure that you
check all the created fields and adapt them. You will come across the same
problem when you work with TDateTime fields.
Bye,
J. Bauer
Bau...@bauer-software.de
> Probably I will drop my Paradox plans, but I really need it to be
> swappable MSSQL/SQL Anywhere.
> Do you think this is optimistic too?
I have no experience with SQL Anywhere. Our app is large and complex,
and we've ended up coding SQL specific to MS SQL server in order to get
it to work well. A change to another server would require tweaking
that SQL, and we'd have to write some kind of tests or conditional
compiles. I would not look forward to it.
True. Tried the access both ways, though, to see if there was a
difference. No difference.
> I check the BDE driver and alias settings VERY carefully <snip!>
Been there, done that. No difference. Set the BDE configs exactly the
same on five different machines. Results:
P166MMX: Integer
P233MMX: Float
P75: Float
P200MMX: Integer
P266: Integer
Tried enabling BCD. No difference. Tried difference drivers (ascii, Dbase
ENU cp437). No difference.
Hmmm.
Cheers,
Cyd
> P166MMX: Integer
> P233MMX: Float
> P75: Float
> P200MMX: Integer
> P266: Integer
Only suggestion I can offer is to uninstall Delphi and BDE, wipe the
directories, and reinstall. Perhaps something is set that's affecting
this. I cannot imagine it's hardware.
It is almost certainly the binding at design time of persistent fields.
An earlier response was on the right track you have to make sure that,
for example, calculated results are returned with the same decimals
places by using convert / declare user data types etc.
I'm getting the same problem with a query like this : SELECT COUNT(*) Total FROM
against a local table. On some machines, Total comes up Integer, on other it
comes with 2 decimals. I ve exported and imported the BDE configuration to make
sure it is the same, with no results... :(
Saludos...
Alexander
> I'm getting the same problem with a query like this : SELECT COUNT(*) Total FROM
> against a local table. On some machines, Total comes up Integer, on other it
> comes with 2 decimals. I ve exported and imported the BDE configuration to make
> sure it is the same, with no results... :(
Same table, same db format (paradox, dbase), same bde version #?
For the first two, yes. The BDE version is either the one that preinstalls the
InstallShield that comes with Delphi 3 C/S or the BDE installs Delphi itself. I
don愒 know if they are different, but I惻l reinstall the BDE in both computers.
However, if this is a BDE-version problem and I install a new version of the
BDE, won愒 other Borland applications developed by others stop working in the
same way?
Thanks...
Saludos...
Alexander
> won´t other Borland applications developed by others stop working in the
> same way?
Maybe, but at least we will know what to put on a bug report.