Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

working with a text file

Status
Not open for further replies.

dinger2121

Programmer
Sep 11, 2007
439
US
Hello,
I have a requirement to allow a user to select a text file and then display the contents of the text file in the browser. I am able to do this with no trouble. I then have to allow the user the opportunity to edit the contents of the text file and ultimately save the data back to a text file (could be a different file).
Would it be best to save the data to a temp database table when it is displayed to screen, make my edits on the database data, and then pull the data back from the db when creating the text new file? Or can I just hold that data in memory and work with it there?

thanks for any thoughts.

carl
MCSD, MCTS:MOSS
 
I believe at this point where you store the data is less important than creating a positive user experience using the information.

how does the user interact with the file? that's a broad question so some other things to think about: is the data sensitive, does security matter? how large is the text file? how often is the data updated? is the data updated in small pieces, or is the data updated all at once? how many people are updating the file? what are the chances of concurrency errors with multiple users editing the file? what are the consequences (cost) of loosing changes during the update process (this may be mute depending on other factors).

once you fully understand how the user interacts with the file you can make technical decisions about how to implement the user experience. Another thing to remember: do the simplest thing possible that will solve the problem. technically speaking databases are quite intrusive and far from simple. however most of us default to a RDBMS for storage and it becomes second nature.

most developers believe there are only 2 places to store data: a RDBMS or in-memory. unfortunately we forget about all the other options. Persistent hash tables, document databases, hierarchical storage, etc. each has it's purpose. a RDBMS isn't a cure-all for data storage, although we commonly treat it as such.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259
 
I think where I'm having trouble is figuring out how to handle data if it were in a text file. If I read in the text file and then dump the data into a temp table, I know how to interact with it. I can work with it how I would normally work with any database data. I can manipulate and then retrieve everything and write it back to a text file.

I think it might be easier to use a text file to work with, but I'm not sure that I can really work with the data once it's in there.

Ultimately, a user has to read in each line from a text file, match it up to some data in a database. From here, the user should be able to edit the data and clean up any errors. After that, I have to produce another text file from the edited data to upload back into the database with any updates, additions, etc.

Hope that makes sense.

carl
MCSD, MCTS:MOSS
 
this sounds like an ETL process with user intervention. I would solve the problem like this:
1. extract data from file. each row is a new object
2. store each object into a persistent hashtable or document db.
3. allow the user to browse each row and edit.
4. pull the data from PHT/doc.DB and push to database/textfile
5. purge the PHT/doc.DB

some tools to assist in development:
Rhino.ETL
Rhino.PHT or Mongo DB
FileHelper

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top