[AccessD] Delimiter Value (was: Automatic Update Function)

Stuart McLachlan stuart at lexacorp.com.pg
Tue Mar 3 14:22:40 CST 2015


If you don't need to file to be easily human readable/editable, there are actually plenty of "low 
ASCII" characters to play with as well (non-printable, <Chr$(32) )

Perhaps Chr$(31) - Unit Separator would be the best.

(And if you use a good editor like NotePad++,  you can display most low ASCII characters 
and edit the file too.)


On 3 Mar 2015 at 11:47, Arthur Fuller wrote:

> This is an interesting thread but I do have one question, which
> derives from personal experience writing a code generator that had to
> find markers in templates and substitute either literal or iterated
> text in place of said markers.
> 
> I opted for two-character delimiters ; they could have been pretty
> much any given character expressed twice. As it happens, I opted for
> "\\marker\\", which admittedly could have created problems when
> attempting to express UNCs etc., but I escaped these in the standard
> way.
> 
> As previously pointed out, the use of the cent-sign may not be
> universal, and that is a problem.
> 
> But my larger question is this: why are you restricting delimiters to
> single-character markers? That seems to me to be the path to trouble
> no matter which native (human or typographical) language you are
> using. Ultimately, this problem resolves to the likelihood of any
> given marker being used within the text of interest; and so we have to
> go for the unlikeliest combinations, the smallest unit being one
> character, but I am arguing in favor of two-character delimiters,
> while also providing for the standard escape-clause syntax of
> repeating the delimiter twice if you mean it not as a delimiter but
> part of the text.
> 
> I've just Googled "the number of official languages in the world", and
> India and China come out way on top, with a few hundred in each
> nation. Just to make this much more painfully clear, "language" is
> distinguished from "dialect", which is to say that even though I have
> lived almost my life in English-speaking Canada, I can also recognize
> Cicero-English from New Orleans English from Oxford English, and also
> readily discern Quebec francais from Parisian and even Marseilles. I'm
> shakier on Dutch, but I can discern Mandarin from Cantonese in fewer
> than 5 seconds, and also Shanghaiese from both of these. You might
> conjecture that I have an ear for language; perhaps that is true.
> After all, I can convincingly pronounce two of the  trickiest words in
> Dutch, but that's because I've visited Nederlands about six times, and
> picked up a little more on each visit. The two most difficult words in
> Dutch are the word for vacuum cleaner (stofzuiger) and the name of a
> town on the coast whose name was used in WWII to distinguish Nazi spys
> from legitimate Dutch citizens (Schlevningen). It required more
> practice for me to get these two words than to apprehend and duplicate
> the tones in Cantonese; but I got there, eventually.
> 
> Sorry for the extensive sidetrack. I just wanted to emphasize that
> single-character delimiters are bound to cause trouble in a large
> number of languages in the world. Facing this ugly fact, the developer
> has a couple of choices: narrow the translation-geography to a few
> well-chosen languages of immediate interest to the app of interest, or
> strive for a broader translation-strategy; in my opinion the only
> viable path to the latter approach is to expand the concept of a
> delimiter beyond single-character representation, and in addition to
> provide the standard escape-syntax (e.g. in py preferred choice, "\\"
> is the delimiter, except when repeated, in which case the second
> occurrence is to be interpreted as literal text).
> 
> This syntax and notation, I hope, will sidestep the fact that the
> "cents" sign will not be misinterpreted by non-English (and in fact
> non-Western-European) keyboards.
> 
> Arthur
> 
> On Tue, Mar 3, 2015 at 11:06 AM, Gustav Brock <gustav at cactus.dk>
> wrote:
> 
> > Hi Tina
> >
> > That character could be: ¤
> > I've seen on every keyboard but never seen it used for anything.
> >
> > However, I've never had issues with the "|" pipe sign, so why make
> > things more strange than necessary.
> >
> > /gustav
> >
> > -----Oprindelig meddelelse-----
> > Fra: accessd-bounces at databaseadvisors.com [mailto:
> > accessd-bounces at databaseadvisors.com] På vegne af Tina Norris
> > Fields Sendt: 3. marts 2015 17:02 Til: Access Developers discussion
> > and problem solving Emne: Re: [AccessD] Delimiter Value (was:
> > Automatic Update Function)
> >
> > This is an intriguing part of the discussion.  One perspective is to
> > find a symbol that will not accidentally be typed because it's not
> > on a standard keyboard.  The other perspective is to find a symbol
> > that can easily be used (because it is on a standard keyboard), but
> > is not commonly used for most typing and coding.  Fascinating.  I
> > like the pipe symbol because it fits with the second perspective.  I
> > would like an ALT+ASCII code symbol that is easy to remember and
> > doesn't appear on a standard keyboard, too, because it reduces the
> > threat of accidental typing.  Hmmm - pondering. TNF
> >
> > Tina Norris Fields
> > tinanfields-at-torchlake-dot-com
> > 231-322-2787
> >
> > On 3/3/2015 8:13 AM, Jim Dettman wrote:
> > >
> > >   I'm not sure if it's as true today as it once was, but using
> > > anything beyond 127 was iffy.
> > >
> > >   The extended characters have no set definition unlike those
> > >   below
> > > 128.  So while that may not exist as a character on a US keyboard,
> > > it may exist on others because it might not be a cent symbol.
> > >
> > >   I use the vertical pipe as well because to my knowledge, there's
> > >   no
> > > place where one would use it outside of computer commands and it
> > > is easy to read because the character is thin.
> > >
> > > Jim.
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan
> > > Waters Sent: Monday, March 02, 2015 08:59 PM To: 'Access
> > > Developers discussion and problem solving' Subject: Re: [AccessD]
> > > Delimiter Value (was: Automatic Update Function)
> > >
> > > Hi John,
> > >
> > > A pretty safe delimiter is a ¢ symbol (cent symbol).  To use it,
> > > you'll have to find it somewhere and copy it into your code.  Or,
> > > you can could also use Chr(162).
> > >
> > > I don't think a cent symbol is on any US electronic keyboards, and
> > > certainly not on any others.
> > >
> > > I found a good list of Chr values at
> > > http://www.gtwiki.org/mwiki/?title=VB_Chr_Values.
> > >
> > > Dan
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W.
> > > Colby Sent: Monday, March 02, 2015 15:32 PM To: Access Developers
> > > discussion and problem solving Subject: Re: [AccessD] Automatic
> > > Update Function
> > >
> > > Of course it was simple.  However if you look at SQL Server export
> > > for example, by default if you tell it to use quotes, it quotes
> > > EVERY FIELD.
> > >
> > > So if you are getting data from the wild, look out.  If you are
> > > doing the export yourself, and then the import yourself, it is
> > > really fairly easy, you control both ends.
> > >
> > > As I mentioned I like pipe delimited because (in MY data) pipes
> > > are unheard of, so using that as a delimiter is pretty safe.  My
> > > data is name / address from the wild, so tabs are encountered
> > > occasionally. I have never actually seen a pipe coming in from raw
> > > data, though of course it is a key on the keyboard and someone
> > > could accidentally hit it.
> > >
> > > John W. Colby
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> 
> 
> 
> -- 
> Arthur
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com





More information about the AccessD mailing list