Import data into a memo field greater than 254 chrs using vfox9 3

[taterday]

I have read and printed tek-tips on the explaination on how to import.

I need to import about 1000 chars per memo into a memo field. Be nice to maintain the formatting.

Using vfoxp 9, are there a better solutions that I can be pointed to or does some one have a sure fire that works. I would really appreciate any help on this.

 

[Dan Freeman]

But as far as I understand this app is supposed to import, what itself exported, so there is no problem, if you export data into dbfs, as you can append those including memo fields.

Have you been having private communications we're not privvy to?

I don't have thoughts on what to use on import from. I would love a suggestion to the best way. Some users have Word, Excel, Access, text? Best would be text, so everyone would have that.

 

[JRB-Bldr]

Some users have Word, Excel, Access, text

Have you ever tried to herd a bunch of cats?

Getting all of your various users trained to output their 'procedures' or whatever documents into a Text format from their varying applications and then ensuring that they are disciplined enough to do so regularly may prove to be a LARGE and challenging task.

That is what it would take to get ALL of the documents into a format which could be input into a Memo field.

I feel like I am 'kicking a dead horse' here by being repetitive, but, with all of those differing user types, good luck in trying to get everything into a singly formatted document style (TEXT) so that functions like:
cFileString = FileToStr("thefile.txt")
will work.

If you cannot get that done then your best bet would be to keep the documents in their 'native' format and storing them somewhere common where everyone can access them - while capturing the reference path & filename into your data table.

Regardless of what approach you take - Good Luck,
JRB-Bldr

 

[Olaf Doschke]

dan,

Here's another quote:

... they want to share the data with other departments, some not located in the same building and do not access. Company policy. They can share tables and the exe is installed on everyone with access.

This means we're talking about one application running in different departments, which are decoupled trechnically into seperate networks, but still only the problem to export and import data from this application to this application.

Bye, Olaf.

 

[Dan Freeman]

Olaf,

What is there about "sharing data across departments" that says exporting? They might want to just share the collected data?

This whole thread seems to have devolved into a discussion of "importing" tabular data when it appears to me the OP is talking about importing documents.

It sounds to me (and it pains me to say this) like this MIGHT (and I choose that word carefully) be a job for a general field. (Those who know me will know I'm the LAST PERSON ON EARTH to recommend a general field.)

If the job is to collect disparate documents in disparate formats and disseminate them then a general field might be the trick. The original data (the documents) can live, and be updated, in their original formats but still be shared and updated at will.

But let's all get back to arguing over importing (and exporting) tabular data, which actually wasn't part of the original question. That's more fun.

 

[Olaf Doschke]

Well dan,

but is "Import data into a memo field ..." the thread name, if it would just be about documents? Also the initial post talks about "about 1000 chars", not documents again.

Memos are for more than 254 chars and can easily be transferred elsewhere if you stay within DBFs.

The discussion about documents came in at the moment tateray mentioned "Some users have Word, Excel, Access, text?"

In my interpretation, dan, and I admit it's just my interpretation, he mentions those file formats as data exchange format. But you can also generate DBFs without any further software needed but a foxpro application he plans to do.

The only reason documents could play a role are for initial input, but then why does he talk about chars only, initially? Or the documents could be meant for output of data into userreadable pretty formatted documents, but that's just the reporting part of an application and not for data exchange.

With this all in mind, do you think I gave a bad advice? I actually don't think this is all about document management. If it is, then taterday has done a bad job in describing what he wants his application to do. Again, that's just my interpretation.

So yes, you may continue to talk about storage of documents, when taterdays problem rather is data exchange of simple texts. He said "line feed for the formatting, nothing special. Sorry for the confusion." So it's rather simple texts like this forums are.

You can easily store them into dbfs, simply put an editbox on your forms for users to enter them and store in memo. Line feed will be stored. Data exchange is easy via COPY TO, which also copies memos and APPEND FROM DBF(), which also appends memos. No problem at all.

Just endless discussions about nothing.

Bye, Olaf.

 

[taterday]

You are right. I have memo fields that the users want to import and export at will... using VFP 9 app.

I am going to use the feature (FileToStr("thefile.txt"). I did not have this feature with vp7 and did not know was available. I have not used 9 expanded features.

Thank you all for your input and helpful advise.

bye

 

[JRB-Bldr]

FileToStr("thefile.txt"). I did not have this feature with vp7 and did not know was available.

Actually the functions FILETOSTR() and its inverse STRTOFILE() is indeed available within VFP7 - look in your VFP7 Help

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

They are even available in VFP6.

Bye, Olaf.

 

[taterday]

Don't tell my users.

Thank you,

 

[Olaf Doschke]

Ok, taterday,

Give me an email adress of a user I shouldn't tell that. ;o)

We've had much talk about the whole thing while you jsut where searching for a possibility to store a memo to text and load it back. Sorry for that.

Theres an easier way thatn STRTOFILE() actually for MEMOs, that is COPY MEMO memofield TO file.txt to store a memo to a txt file and APPEND MEMO memofield FROM file.txt OVERWRITE to read it back in.

Both this and STRTOFILE/FILETOSTR are cumbersome commands though, if you want to export or import a large number of memos/text files.

Bye, Olaf.

 

[craigber]

It's sounding more and more like you should use SQL Server and store the files in it. You can store them in whatever native format they were created and you don't have a 2 Gig file limitation.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[taterday]

Hi Craig,

I agree that SQL could be the best solution but the SQL Server is not available to all the users.

Thank you for the suggestion. It was right on.

 

[craigber]

So, what are the issues with making SQL Server available to all the users?

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[taterday]

No access and management decision. SQL is for the main production system.

I am giving a problem to solve and am expect to stay within the constraint of present configuration. Freedom to do what may be a better solution is not acceptable in my envirnoment.

"Make it work." It is what it is.

Thank you guys,

bye