John W. Colby
jwcolby at gmail.com
Mon Mar 2 13:11:45 CST 2015
Janet, CSV is a standard used to "wrap" data that might contain commas (addresses for example) in double quotes - " - and then "separate" the fields with commas. So you end up with something like: "Data1", "data2", "data3" CRLF "Data4", "Data5", "Data6" CRLF Etc. As a standard, it works as well as any other. The problem is that some folks don't use the enclosing quotes, and then if a comma slips into the data, the importer things there is an extra field in the line and all ... breaks loose. Tab delimited doesn't necessarily solve that problem. I often use pipe delimited since the pipe is less often used than tab. If you have control of both ends, just use CSV and don't worry about it. John W. Colby On 3/2/2015 11:52 AM, Janet Erbach wrote: > Stuart - what specific PITA issues are you referring to? I did already > create the CVS logic...but since I'm going to be continuing to mess with > the guts of this thing for a while yet, I could always change it. What > experience have you had with CSV? > > On Fri, Feb 27, 2015 at 2:28 PM, Stuart McLachlan <stuart at lexacorp.com.pg> > wrote: > >> Just back in Port Moresby after three weeks in Bougainville working on >> electoral roll updates >> where we had a dozen DPOs working 24/7 using a split Access application. >> >> BER.accdb is the front end. >> >> This is the contents of a .cmd file that sits on each PC (with a shrotcut >> to it on the desktop): >> >> @copy \\BERMSERV\BERMS\BER.accdb c:\BER >> @START C:\BER\BER.accdb >> >> I can drop a new copy of BER.accdb on the server at anytime. >> Every time the operator starts the application, they get a new copy of it. >> It is also handy in >> avoiding bloat if you use termporary tables in the FE. >> >> BTW, don't write to CVS (comma separated values)- that format is a PITA >> to work with. use >> Tab separated) >> >> -- >> Stuart >> >> On 27 Feb 2015 at 8:44, Janet Erbach wrote: >> >>> Hello all - >>> >>> Do any of you have a favorite approach/module that you use to >>> automatically update the front end on the user's machine? My monster >>> application from WIFI hell has had auto update issues as well as >>> corruption issues. >>> >>> My co-worker that developed part of the app with me wrote an auto >>> update module that >>> >>> Creates a batch file on the fly >>> Closes Access >>> Runs the batch file to copy the new front end to the user's machine >>> and then re-opens access >>> >>> At least that's what's supposed to happen...there have been a number >>> of times that I've been suspicious about whether or not this auto >>> update is somehow triggering back-end corruption too, although I don't >>> know why it would. There have been many times when the app is up and >>> running fine on 10 machines and when the 11th machine starts up and >>> goes into auto-update mode the whole thing comes crashing down. Maybe >>> that's just coincidence. >>> >>> BTW, I'm implementing the 'write to CSV' option today to try and stop >>> the corruption... >>> >>> Janet Erbach >>> -- >>> AccessD mailing list >>> AccessD at databaseadvisors.com >>> http://databaseadvisors.com/mailman/listinfo/accessd >>> Website: http://www.databaseadvisors.com >>> >> >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >>