On 2019-02-22 14:50, Kevin Cully wrote:
There are a ton of VFP developers and they've never reached out to
their community to improve their skills and it shows in their code.
So true! Together, we're better.
___
Post Messages to:
Forgive yourself and move on. :D We've all made bad design decisions
at one point or another in the past. The most important part is that
you are active in a developer community and seek to do better. I hope
that I am a better developer today than I was yesterday. There are a
ton of VFP
On 25/02/2019 17:10, John Weller wrote:
> I should have said given Gt Ducie St - that brings back memories of
> commuting between Salford and Manchester Grammar many, many years ago!
>
It's more or less the same now, but with worse traffic :-(
Oh and Boddington's brewery has gone.
Peter
This
At 09:00 2019-02-25, Ted Roche wrote:
On Mon, Feb 25, 2019 at 11:38 AM Ed Leafe wrote:
> They are presumably being used as PKs for tables representing humans, no?
> Then the vast majority of potential records would have null values, since
> most humans are not citizens of the USA.
Ur either
At 08:38 2019-02-25, Ed Leafe wrote:
On Feb 25, 2019, at 10:26 AM, Ted Roche wrote:
>
> There's a couple of issues with using SSNs.
>
> Technically, they are not unique. Several people have received duplicate
> numbers, so they're not ideal primary keys.
They are presumably being used as PKs
I should have said given Gt Ducie St - that brings back memories of
commuting between Salford and Manchester Grammar many, many years ago!
John Weller
01380 723235
07976 393631
You inherited a boot brush? That's a new one on me :-)
___
Post
Uh oh Ted - this kinda comment could push this thread into the Devious
world of the OT Territory!!!
For the heck of it - I Googled the term - and I found it kind funny what
was written up in the Urbandictionary:
"Those Muricans think they can just push everyone around. What abunch
On 25/02/2019 16:53, John Weller wrote:
> Thanks Ted, that explains it well. We have a similar number, the National
> Insurance Number, which is unique and is not considered 'secret' at least as
> far as I am aware, but that is random and includes a check digit. I don't
> think I would use
On Mon, Feb 25, 2019 at 11:38 AM Ed Leafe wrote:
> They are presumably being used as PKs for tables representing humans, no?
> Then the vast majority of potential records would have null values, since
> most humans are not citizens of the USA.
>
Ur either Muricans, or your not. ;)
But
Thanks Ted, that explains it well. We have a similar number, the National
Insurance Number, which is unique and is not considered 'secret' at least as
far as I am aware, but that is random and includes a check digit. I don't
think I would use it as it is too cumbersome.
I know what you
On Feb 25, 2019, at 10:26 AM, Ted Roche wrote:
>
> There's a couple of issues with using SSNs.
>
> Technically, they are not unique. Several people have received duplicate
> numbers, so they're not ideal primary keys.
They are presumably being used as PKs for tables representing humans, no?
John:
There's a couple of issues with using SSNs.
Technically, they are not unique. Several people have received duplicate
numbers, so they're not ideal primary keys.
Second, they are considered "secret" Personally Identifiable Information
(often PII) and disclosure of such information can be a
Purely out of curiosity and not being familiar with your SSNs (Social
Security Numbers I assume) can I ask what is the problem with using them as
a PK?
John Weller
01380 723235
07976 393631
I must confess I did this once and used SSN's as a primary key. It is my
shame
Subject: Re: false news
On Fri, Feb 22, 2019 at 6:11 AM Kevin J Cully
wrote:
> I had a potential client where they based their primary keys based on
> employee Social Security Numbers. They didn't like it when I told them
> that they'd need a complete rewrite. Notice this would have been
On Fri, Feb 22, 2019 at 6:11 AM Kevin J Cully
wrote:
> I had a potential client where they based their primary keys based on
> employee Social Security Numbers. They didn't like it when I told them
> that they'd need a complete rewrite. Notice this would have been the case
> no matter what
Well, a lot of that article is correct, even though I don't want it to be. VFP
as a *language* is as secure as the programmer programmed it to be. VFP as a
*database* isn't secure itself. You can encrypt fields. You can encrypt the
directory that the data is stored in. But DBF data isn't
16 matches
Mail list logo
