dbTalk Databases Forums  

importing large data fields

comp.databases.paradox comp.databases.paradox


Discuss importing large data fields in the comp.databases.paradox forum.



Reply
 
Thread Tools Display Modes
  #41  
Old   
Anne Wainwright
 
Posts: n/a

Default Re: importing large data fields - 06-15-2008 , 12:59 PM






Jim, hello,

That sounds good simple advice, I'll investigate that on the basis of a script to get
the stuff in to Pdox (v.9 i think).

see comment below.

thanks
Anne

On Sat, 14 Jun 2008 19:26:58 -0400, Jim Hargan wrote:

Quote:
Hi Anne!

I can't address the import routines (interactive or OPAL, which has an
entire datatype devoted to them); I've found them so powerful that I've
never run up any of their limits! But evidently you have.
Honestly i was just following the onscreen instructions and importing from
a one-line per record with fields separated by '|' so nothing complex when
it told me 'no can import into 'Memo' field' and I am certain the online
help backed that up. Can't look at that now, in linux os.

At the time it didn't matter, losing a few hundred chars only, but it will
matter later when that data is needed. Not that it has the same import as
War & Peace, but then as a book database i might just have those very
words in a record!

Quote:
Fortunately, you also have the textStream type. When I first read the OPAL
help on it I thought there had to be a catch; nothing is this simple. I
found out that, yes, it really is that simple.

TextStream methods read and write text files. If your source is any sort of
text file, you can use textStream methods to read it into string variables,
one line at a time. String variables since v7-32 (I think) have no limit on
size -- none at all. You can cram /War and Peace/ into a single string
variable if you want. Then you write it into a memo field:
myMemoField'value = stWarAndPeace.

How you do this depends on the way your source is formatted. If your source
uses a field delimiter that does not appear within the fields, then it's
easy -- use textstream to read each line of the source into a string
variable, then use breakApart on the delimiter. For CSV, advMatch on
..\\",\\".. suggests itself, although I've never tried it myself.

HTH

Jim Hargan

On Sun, 15 Jun 2008 00:39:24 +0200, Anne Wainwright wrote:

hello, me again.

I am importing data larger than 256 chars per field, but cannot import
into a memo fieldit seems.

Conversely, if I have a memo field then when i export to a separated
format then only the first 256 chars get out.

These seem to be the basic limitations in the interactive mode. I haven't
looked at it in great detail, but are there ways around this without
clever code (or even with it)?

Thanks for any comments.
Please reply to newsgroup only.

Anne


Reply With Quote
  #42  
Old   
Anne Wainwright
 
Posts: n/a

Default Re: importing large data fields - 06-15-2008 , 12:59 PM






Jim, hello,

That sounds good simple advice, I'll investigate that on the basis of a script to get
the stuff in to Pdox (v.9 i think).

see comment below.

thanks
Anne

On Sat, 14 Jun 2008 19:26:58 -0400, Jim Hargan wrote:

Quote:
Hi Anne!

I can't address the import routines (interactive or OPAL, which has an
entire datatype devoted to them); I've found them so powerful that I've
never run up any of their limits! But evidently you have.
Honestly i was just following the onscreen instructions and importing from
a one-line per record with fields separated by '|' so nothing complex when
it told me 'no can import into 'Memo' field' and I am certain the online
help backed that up. Can't look at that now, in linux os.

At the time it didn't matter, losing a few hundred chars only, but it will
matter later when that data is needed. Not that it has the same import as
War & Peace, but then as a book database i might just have those very
words in a record!

Quote:
Fortunately, you also have the textStream type. When I first read the OPAL
help on it I thought there had to be a catch; nothing is this simple. I
found out that, yes, it really is that simple.

TextStream methods read and write text files. If your source is any sort of
text file, you can use textStream methods to read it into string variables,
one line at a time. String variables since v7-32 (I think) have no limit on
size -- none at all. You can cram /War and Peace/ into a single string
variable if you want. Then you write it into a memo field:
myMemoField'value = stWarAndPeace.

How you do this depends on the way your source is formatted. If your source
uses a field delimiter that does not appear within the fields, then it's
easy -- use textstream to read each line of the source into a string
variable, then use breakApart on the delimiter. For CSV, advMatch on
..\\",\\".. suggests itself, although I've never tried it myself.

HTH

Jim Hargan

On Sun, 15 Jun 2008 00:39:24 +0200, Anne Wainwright wrote:

hello, me again.

I am importing data larger than 256 chars per field, but cannot import
into a memo fieldit seems.

Conversely, if I have a memo field then when i export to a separated
format then only the first 256 chars get out.

These seem to be the basic limitations in the interactive mode. I haven't
looked at it in great detail, but are there ways around this without
clever code (or even with it)?

Thanks for any comments.
Please reply to newsgroup only.

Anne


Reply With Quote
  #43  
Old   
Anne Wainwright
 
Posts: n/a

Default Re: importing large data fields - 06-15-2008 , 12:59 PM



Jim, hello,

That sounds good simple advice, I'll investigate that on the basis of a script to get
the stuff in to Pdox (v.9 i think).

see comment below.

thanks
Anne

On Sat, 14 Jun 2008 19:26:58 -0400, Jim Hargan wrote:

Quote:
Hi Anne!

I can't address the import routines (interactive or OPAL, which has an
entire datatype devoted to them); I've found them so powerful that I've
never run up any of their limits! But evidently you have.
Honestly i was just following the onscreen instructions and importing from
a one-line per record with fields separated by '|' so nothing complex when
it told me 'no can import into 'Memo' field' and I am certain the online
help backed that up. Can't look at that now, in linux os.

At the time it didn't matter, losing a few hundred chars only, but it will
matter later when that data is needed. Not that it has the same import as
War & Peace, but then as a book database i might just have those very
words in a record!

Quote:
Fortunately, you also have the textStream type. When I first read the OPAL
help on it I thought there had to be a catch; nothing is this simple. I
found out that, yes, it really is that simple.

TextStream methods read and write text files. If your source is any sort of
text file, you can use textStream methods to read it into string variables,
one line at a time. String variables since v7-32 (I think) have no limit on
size -- none at all. You can cram /War and Peace/ into a single string
variable if you want. Then you write it into a memo field:
myMemoField'value = stWarAndPeace.

How you do this depends on the way your source is formatted. If your source
uses a field delimiter that does not appear within the fields, then it's
easy -- use textstream to read each line of the source into a string
variable, then use breakApart on the delimiter. For CSV, advMatch on
..\\",\\".. suggests itself, although I've never tried it myself.

HTH

Jim Hargan

On Sun, 15 Jun 2008 00:39:24 +0200, Anne Wainwright wrote:

hello, me again.

I am importing data larger than 256 chars per field, but cannot import
into a memo fieldit seems.

Conversely, if I have a memo field then when i export to a separated
format then only the first 256 chars get out.

These seem to be the basic limitations in the interactive mode. I haven't
looked at it in great detail, but are there ways around this without
clever code (or even with it)?

Thanks for any comments.
Please reply to newsgroup only.

Anne


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.