I'm wondering if there is any [easy] way to prevent data loss when altering an existing ftString field into an ftMemo field type? I've tried the process via DBSYS (in v3 as well as v4) and it
seems to null any existing string data when performing the field conversion -- along with the requisite warning dialogs. I'm pretty sure what I know what the answer is (i.e. "no"), but I figured
I'd ask just the same.

Jason

PS: Looking forward to saying "hi" Tim when you're in Toronto next week!

go thru a three step process

alter table add memo;
update table set memo = string;
alter table drop string;

Robert

"Jason Wilson" <jason@globestarsystems.com> wrote in message
news:B0695195-1355-45E1-A635-F1B018E3EE8E@news.elevatesoft.com...
> I'm wondering if there is any [easy] way to prevent data loss when
> altering an existing ftString field into an ftMemo field type? I've tried
> the process via DBSYS (in v3 as well as v4) and it
> seems to null any existing string data when performing the field
> conversion -- along with the requisite warning dialogs. I'm pretty sure
> what I know what the answer is (i.e. "no"), but I figured
> I'd ask just the same.
>
> Jason
>
> PS: Looking forward to saying "hi" Tim when you're in Toronto next week!
>

<<
"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote:

go thru a three step process

alter table add memo;
update table set memo = string;
alter table drop string;

Robert
>>

Thanks for your reply, Robert. As silly as it sounds, that's a bit more complicated than I was hoping for. Presently we have a fairly comprehensive utility embedded in our server application
that automatically updates, restructures and repairs any earlier version of our database (over 45 and counting) to the latest structures. Unfortunately, it is a decidedly "single-pass" design and
your very sensible suggestion wouldn't quite fit that model. I was really hoping that DBISAM itself would be able to magically migrate the string data into the memo field, as the field types are
somewhat compatible (at least in that direction). As it stands, I'll likely live with the 512 character limit of the string fields for the moment -- that is unless Tim chimes-in to berate me for my
foolishness in forgetting to set a property or parameter that clearly supports the preservation of the data.

Cheers,

Jason

Jason,

<< I'm wondering if there is any [easy] way to prevent data loss when
altering an existing ftString field into an ftMemo field type? I've tried
the process via DBSYS (in v3 as well as v4) and it seems to null any
existing string data when performing the field conversion -- along with the
requisite warning dialogs. I'm pretty sure what I know what the answer is
(i.e. "no"), but I figured I'd ask just the same. >>

The answer is basically no, but I'll see what I can do for the next DBISAM
build.  I'm not sure why this wasn't addressed yet, but it should have been.

<< PS: Looking forward to saying "hi" Tim when you're in Toronto next week!
>>

Great, it looks like the turnout is going to be good.  I just hope that I
can time the drive/train/subway properly so that I'm not late.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<"Tim Young [Elevate Software]" wrote:

The answer is basically no, but I'll see what I can do for the next DBISAM
build.  I'm not sure why this wasn't addressed yet, but it should have been.>>

Hi Tim, this particular topic came up again due to some database upgrades we're doing in our product. I was immediately transported on a trip down memory lane when the very first hit on my Google search brought up this same forum thread from seven years ago

I just tried again to change the field type from string to memo using DBISAM 4.29 build 4, and the contents of the string fields are still getting ablated during the upgrade. Is there a top secret setting that I'm missing, or is it still on the "todo" list?

Cheers,

Jason

Jason,

<< I just tried again to change the field type from string to memo using DBISAM 4.29 build 4, and the contents of the string fields are still getting ablated during the upgrade. Is there a top secret setting that I'm missing, or is it still on the "todo" list? >>

Yeah, I completely forgot about this, so thanks for pinging me.  I'm doing some DBISAM work today, so I'll fit it in.  Look for it in the 4.42 B2 build, but I can also send you guys a hot-fix directly if you want.  Just email me with the email address that you want me to send it to.

Tim Young
Elevate Software
www.elevatesoft.com

It's done.

Tim Young
Elevate Software
www.elevatesoft.com

<<Tim Young [Elevate Software] wrote:

It's done.>>

Well that was fast work Tim! It only took you a few hours, plus or minus 7 years

We can certainly hang on until your next official build is released, no need to prepare a special package.

Thanks again!

Jason

Jason,

<< Well that was fast work Tim! It only took you a few hours, plus or minus 7 years>>

I was thinking the same thing.

This feature has been requested a lot, but for some reason I had this mental block that it was going to be a big PIA and a lot of work.  As soon as I got it done in about 20 minutes, I said to myself "son of a b***h".....

Tim Young
Elevate Software
www.elevatesoft.com

<< Tim Young [Elevate Software] wrote:

This feature has been requested a lot, but for some reason I had this mental block that it was going to be a big PIA and a lot of work.  As soon as I got it done in about 20 minutes, I said to myself "son of a b***h".....>>

Tim, just noticed the latest DBISAM 4.42 (Build 2) update -- thanks for keeping the DBISAM flame alive!. That said, I don't recall seeing the above fix referenced in this or any of the preceding updates since your last profanity-laden post. Granted, I'm old and inattentive, my vision is failing and I'm certifiably senile, so I likely just missed it. However can you please confirm whether the fix did indeed make it into production?

Cheers,

Jason