Janet Erbach
jerbach.db at gmail.com
Mon Mar 2 13:52:51 CST 2015
Ah. Thank you for spelling it out - I am aware of the issues you mentioned, and am not concerned for this app that commas will slip in to mess things up. I was concerned that there might be another 'gotcha' that I hadn't run into yet. :) I will leave it as CSV then, since it's already written that way. On Mon, Mar 2, 2015 at 1:11 PM, John W. Colby <jwcolby at gmail.com> wrote: > 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 >>> >>> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >