Re: JSON Tools Was: Re: C-objects and memory use

[David Adams via 4D_Tech]

On Tue, Aug 8, 2017 at 5:14 PM, Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> it seems this view just keeps coming up...
>


> I am sorry if the documentation or marketing material or presentation or
> some other form of communication gave the wrong impression, but Object and
> Array Object are not "4D's way of supporting JSON".
>

Thanks for saying this so clearly. This is the reality that is behind my
feature request(s) for a set of native tools to deal with arbitrary JSON
input/output. For now, I've got NTK but it is a feature set that any modern
tool should have out of the box.
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Relative path in SVG DOM

[Keisuke Miyako via 4D_Tech]

is your SVG image itself a file inside the Resources folder?

> 2017/08/09 2:45、Two Way Communications via 4D_Tech <4d_tech@lists.4d.com> 
> のメール：
> However, if I put this inside the xlink:href attribute of the image, it does 
> not show up in the SVG.




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: JSON Tools Was: Re: C-objects and memory use

[Keisuke Miyako via 4D_Tech]

it seems this view just keeps coming up...

I think it is important to understand that 4D didn't look at JSON and implement 
it as Object and Array Object, doing a really bad job at it, as it were, no, it 
happened the other way round... Object and Array Object were implemented first, 
and then JSON was chosen as a practical way to stringify these new native data 
types. as such, it should not come as a surprise at all that not every JSON can 
be converted to a 4D Object or Object Array. I am sorry if the documentation or 
marketing material or presentation or some other form of communication gave the 
wrong impression, but Object and Array Object are not "4D's way of supporting 
JSON".

> 2017/08/09 5:42、Rick Hazey via 4D_Tech <4d_tech@lists.4d.com> のメール：
>
> [ 1, 2, 3 ]
>
> 4D couldn’t parse it.




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Rotating Pictures

[Timothy Penner via 4D_Tech]

Hi Cannon,

> Does anyone have any ideas about how to do this?

I think you could use SVG_SET_TRANSFORM_ROTATE:
http://livedoc.4d.com/4Dv15/help/Command/en/page65945.html

The idea would be to create a new SVG canvas and embed the picture on it, then 
rotate the SVG, then export the SVG back to an image.

This is already done for you and packaged in a component here:
https://github.com/miyako/4d-component-rotate-picture
(Thanks Miyako!)

-Tim





**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Rotating Pictures

[Cannon Smith via 4D_Tech]

I should mention that the pictures are JPEGs, if it matters.

--
Cannon.Smith
Synergy Farm Solutions Inc.
Hill Spring, AB Canada
403-626-3236




> On Aug 8, 2017, at 5:01 PM, Cannon Smith via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> I was surprised that the TRANSFORM PICTURE doesn’t have the ability to rotate 
> a picture. I have the need to programmatically rotate a picture before 
> displaying it on a form based on the EXIF rotation data. I’d like to do this 
> natively, if possible, and it needs to work on both Mac and Windows. Does 
> anyone have any ideas about how to do this?

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Rotating Pictures

[Cannon Smith via 4D_Tech]

I was surprised that the TRANSFORM PICTURE doesn’t have the ability to rotate a 
picture. I have the need to programmatically rotate a picture before displaying 
it on a form based on the EXIF rotation data. I’d like to do this natively, if 
possible, and it needs to work on both Mac and Windows. Does anyone have any 
ideas about how to do this?

Thanks.

--
Cannon.Smith
Synergy Farm Solutions Inc.
Hill Spring, AB Canada
403-626-3236




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: JSON Tools Was: Re: C-objects and memory use

[Kirk Brooks via 4D_Tech]

Rick,
You have to use the JSON PARSE ARRAY command.

http://doc.4d.com/4Dv15/4D/15.4/JSON-PARSE-ARRAY.301-3274446.en.html

I wrote a wrapper for JSON strings to look at the first char and then use
the appropriate method.

This is one place where NTK is more convenient since it makes that
adjustment automatically. Which it can do since it simply returns a handle
to the newly created JSON object. 4D can't because it goes ahead and parses
the string into a 4D typed var.

On Tue, Aug 8, 2017 at 1:42 PM, Rick Hazey via 4D_Tech <4d_tech@lists.4d.com
> wrote:

> It’s been a long time since I’ve used 4D and JSON but as I recall one
> problem was the inability to parse JSON where the top level is an array
> instead of an object. IOW, if your JSON looked like this:
> [ 1, 2, 3 ]
>
> 4D couldn’t parse it.
>
-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: JSON Tools Was: Re: C-objects and memory use

[Rick Hazey via 4D_Tech]

It’s been a long time since I’ve used 4D and JSON but as I recall one problem 
was the inability to parse JSON where the top level is an array instead of an 
object. IOW, if your JSON looked like this:

[ 1, 2, 3 ]

4D couldn’t parse it.

A pretty big deviation from the standard. On the other hand, you can test for a 
top level array, wrap it in an object, and go about your business.

I wrote a JSON parser in 4D code way back in 2011 (and did a Summit session 
about it in 2012) that has no problem handling any valid JSON. Maybe the new 
collection type will allow parsing of top level JSON arrays. Regardless, the 
collection type is a nice addition to the language.


Rick Hazey 
Octet Industries, LLC 
--- 
r...@octethosting.net  
--- 
WWKD?

> On Jul 26, 2017, at 3:13 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> ​At the risk of appearing really dense what are the specific things you can
> do with NTK that you can't do with native 4D? I use them both and I just
> don't get what you are referring to. There are differences in the way they
> provide access but I don't see how that results in a limit to what you can
> do.
> 
> And like I said currently you can use native 4D tools to parse a c-obj and
> make a change to a single key of a nested obj and the parent object is
> updated (anyone joining in here should probably read the other thread for
> the details). This is because of the object referencing we talked about in
> the other thread. NTK doesn't support that right now so you can't do it.
> Personally I find that really useful.
> 
> Can you give me an example of the kind of situation you're talking about?​

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Relative path in SVG DOM

[Two Way Communications via 4D_Tech]

I am trying to use a relative path to a picture file that is stored locally, in 
the database folder.

According to the documentation:

A relative URL ("../picture.png"). This is particularly useful in client/server 
mode, when files are stored in the "Resources" folder. Relatives URLs can begin 
with:
"/", to indicate the "~/Resources/SVG/" path
"./", to indicate the "~/Resources/" path
"../", to indicate the database folder.
However, if I put this inside the xlink:href attribute of the image, it does 
not show up in the SVG.

Has anyone come across this?

I am using 16R4 at the moment.


Kind regards,

Rudy Mortier
Two Way Communications bvba  -



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: ​Re: UUID vs Longint primary key

[David Adams via 4D_Tech]

> This all started with David making a broad blanket statement about "data
> integrity" and "row duplication" and how using "synthetic" record ID keys
> ruined the ability to automatically​ ​filter out "dupes". (I _think_ that
> was your point David. Please correct me if not.) And in that strict sense,
> if a "row" is really actually

I've been a bit taken aback at how this thread has gone, to be honest.

My point was really basic: Bolding on a random number field makes a row
unique, it doesn't make the underlying *data* unique.

That's it. That's more-or-less me using one of my standard techniques:

1) Find the obvious.
2) Draw a circle around it.
3) Declare it mine.

Patent pending...

Seriously, I'm saying something that just shouldn't be even the tiniest bit
contentious. That point is nothing but an established principle from
database design, it's not something I'd normally consider debatable. I'd
put it in the same category as when someone says, "Race condition? I've
figured out a shortcut." No you haven't. That's pretty much in line with
things the patent office won't even review:

* Perpetual motion machines.

* Squirrel-proof bird feeders.

Until such time as the fundamental laws of nature change, neither of those
inventions can work.

A lot of the stuff about duplicates doesn't bear on the design question
about the table's columns.

Keller 123
Keller 123
Keler 123

How many rooms are there? You have no way to know. It could be 1, 2, or 3:

1: You've got a pure duplicate and a typo-based duplicate.
2: You've got a pure duplicate and two buildings with very similar names.
3: You've got two buildings with very similar names *and you are missing
enough data to identify rows uniquely.*

In that last case,there's a design question. If you haven't identified
enough columns of *data* from the real world to uniquely identify each row,
you don't have a data model that can be implemented in a relational
database. I mean, sure, you can use a tool to store the data - but I don't
see how you model that. What makes each row unique? I mean out in the real
world. Perhaps there's a floor, or a direction, or some kind of vernacular
detail that actual people use to distinguish rooms. In which case, you've
found a missing field! That's part of the point of modeling. But what if
there really is nothing? Well, then it's pretty common to add something,
like a number. But that then (generally) needs to flow out into the real
world. So, you synthesize data in the database, add it to the row *and* to
the real world. Serial numbers are a perfect example of this. Same with
account numbers, customer numbers, etc. And UUIDs are functionally serial
numbers. They have nothing at all to do with the data in the row, they're
purely an implementation-level convenience.

As some people seem to be getting the impression I'm against UUIDs, that's
incorrect. I'm glad they're native (I used them sooner than that), I've got
nothing against them. But they are what they are and not more. Any
complaints I had about how they were implemented in 4D is irrelevant now as
it's been since V14. Too old to matter. I also have been getting the
impression when people say "primary key", they don't always appreciate what
a "key" really is - an attribute or set of attributes that are entirely
about the row of data that also uniquely identify a row. That's a key...off
the top of my head, I'm sure there's a better summary out there. The 4D
world has long had a peculiarly hostile relationship to normalization,
starting with 4D itself (subtables, wrong examples in the manuals, etc.)
I've seen the same cropping up again with how object fields are being
promoted. (Slapping some JSON in a text field and calling your system NoSQL
isn't necessarily helpful...)

But just slapping a random-but-unique number (sequential or not) onto the
row? That easily masks real duplicates. And why other databases prominently
support multi-field constraints on tables - for precisely this reason.
Again, you *can* do this in 4D with a compound index set to unique. So, the
feature exists, I just haven't seen it being used widely. Perhaps it
because engine-level errors feel disproportionately painful to deal with in
4D? That could just be me. Sincerely, I may be more allergic to 4D
engine-level errors than others. I pretty much turn off the unique
attribute and check uniqueness myself. Hmmm. I might be missing upping my
game here. I kind of remember that years ago hitting a duplicate error
wasn't easy to trap for and got ugly. I can't swear that's true, I just
remember having that impression. Long story shorter, I probably
haven't tried 4D's uniqueness controls in years. Do people use them? How
are they in V16? Since I'm doing some Postgres stuff these days, yeah, over
there I set up multi-column constraints, no question.

There are lots of other kinds of duplicates out there that can crop up,
even if you have a good model behind your tables. Life is hard. But it's
important and 

​Re: UUID vs Longint primary key

[steve simpson via 4D_Tech]

On Tue, Aug 8, 2017 at 11:00 AM,
​
Chip Scheide <4d_o...@pghrepository.org> wrote:

>
> Worse, I've found that the same product, from the same vendor in
> differing purchase amounts (1 vs case) is the same part number, but
> different pricing! So.. even a check on part numbers is insufficient to
> stop duplicate entries.
>
> ​Well I believe there are "dupes" and then there are dupes. There are
unacceptable dupes and there are dupes you have to or need to live with.
And then there are "near dupes". Like your example above. That is not
"really" a dupe because there is one field/col, pack size, that is NOT
duplicated (case vs 1). On and on.

This all started with David making a broad blanket statement about "data
integrity" and "row duplication" and how using "synthetic" record ID keys
ruined the ability to automatically​

​filter out "dupes". (I _think_ that was your point David. Please correct
me if not.) And in that strict sense, if a "row" is really actually
absolutely duplicated, that is _probably_ bad. Or maybe not if you didn't
include that "pack size" field that would have changed the row to unique.
Or all the other examples cited on this thread about duplicate names that
were not _really_ duplications; they just needed a little more information
included in the "row" to better define it. In fact we all used to
experience it right here nearly daily with our Walt Nelson(Guam) vs Walt
Nelson(Seattle) signatures. Constantly confusing without that one little
added tidbit.

So my point was, ​it all depends. And sometimes you have to design your own
system differently or provide tools within your current system to suss out
what, how, why and when a "dupe" occurred. And how to - or IF to - fix it
or prevent it or even find it.

I too am definitely a convert to using
 UUID over longint
​. AND in using them in preference to some construction using row data
itself which may well change as the business grows/changes and will NOT
play well when you absorb new data sources (buy a competitor for example
with nearly identical inventory items or combine existing standalone data
installations into one big common enterprise bucket, or decide for all
kinds of business reasons to extract a certain batch and combine it with
another batch in a different bucket, etc.etc.etc. Data duplication of one
sort or another are bound to occur in many of these "growth" scenarios and
more often than not the merging and cleaning of those dupes is not
reducible to some sort of algorithm without human hands to help. Or
whatever.

As ​
Neil succinctly describe
​d
:

 - UUID is faster (do to "random" data in the index)
>  - UUID solves problems with distributed systems that sync
>  - UUID fixes the home grown sequence problem with transactions
>  - UUID is not easily readable by human and keeps me from being tempted to
> expose them :)
>
> ​And to Chip's point, I DO sometimes expose those UUIDs as read only info
on certain Admin Review pages. I sometimes place a button to "copy to
pasteboard" if it is appropriate that the admin might desire to do some
searching with that UUID - for as we all know​, they are hellishly
difficult to type. And in many projects I retain that seq longint idea
because it really IS a useful human marker that is easier than a date:time
stamp to read and quickly sort on and in general "glom" as you scan down
long lists of rows. But I've been burned way too many times to ever use it
again as a unique recordID. I now consider it a user interface type aid
only, still useful as a ProductID or some such in many cases. But not as a
Unique-Unvarying-Forever-Regardless-Of-Source-Or-Destination-Record-Key.

Steve Simpson
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Re(4): 4D db -> SAAS

[Jim Labos - infobase via 4D_Tech]

Unless I misunderstood the requirement, if it's a single user application and
the Data is particular to each customer but not the schema/structure than
why not use 4D Volume Desktop?

Cheers

Jim Labos - infobase



-
Jim Labos - infobase
--
View this message in context: 
http://4d.1045681.n5.nabble.com/D3-js-Wow-Some-notes-on-SVG-D3-and-data-visualizations-tp5741826p5753601.html
Sent from the 4D Tech mailing list archive at Nabble.com.
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Preventing Duplicate Data WAS UUID vs Longint primary key

[Jody Bevan via 4D_Tech]

Chip:

I have always tried doing at the point of data entry. Obviously no code is 
perfect, and either is the object between the keyboard and the chair. My 
experience is that few Administrators would take the time to filter through 
duplicates. Getting them to do system maintenance was almost impossible. They 
had too many other responsibilities. Typically they only worked on this if a 
problem was identified. For that we have a built in record merger.

Application: Medical

If a phone number is associated with the record for an individual - then I will 
use that. How it is implemented depends on the application (even within the 
application).

Lets say I am adding in a person. They enter in a name (which is not that good 
as people will call themselves by different names). I remember one patient that 
would present with a different name (About 6 personalities) in a walk in 
clinic. If a new record was going to be created they would try and get a phone 
number from the patient. When the phone number was put in a dialog would come 
up displaying all the names of people with the same phone number. It let the 
staff (if they ‘felt like it’) to try and filter for duplicates at that point.

For those staff that were diligent it prevented many duplicates in the medical 
data base. We had clinics that had 420,000 ‘regular’ patients. Then they had a 
walk in that had another 500,000 irregular patients. Their Administration was 
more eager to keep the duplicates down.

We also used the Health Insurance Number as another indicator. Not all 
patient’s would present with their health care card though. With ‘universal’ 
health care it is not as critical.

Application: National Order / Deliver Desk

We do the same in Canada for Postal Code and Street name

With a national order delivery system we had the addresses divided up so that 
we could look up Postal Codes (Canada) by address. This was also used for 
keeping duplicates down. This is when I learned that in Canada Postal Codes 
change weekly (nationally - there are postal codes changing somewhere).


Looking in your system for unique or even semi-unique data can be used to help 
keep duplicates down.
In the medical system we let them have a picture in the patient’s record that 
was presented (if security settings permitted) at the time of entry to the 
facility.

Those are the ones that I have used.

Jody



Jody Bevan
ARGUS Productions Inc.
Developer

Argus Productions Inc. 




> On Aug 8, 2017, at 8:25 AM, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Jody,
> what are your normal duplicate reducing/removal technic(s)?

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: ​Re: UUID vs Longint primary key

[Chip Scheide via 4D_Tech]

ok - I'm confused.
what is the difference between a display only field showing an internal 
ID number,
and a duplicate, display only ID number showing on the entry form?

 
On Tue, 8 Aug 2017 08:07:00 -0600, npdennis wrote:
>> I find that by placing the internal linking value (non-editable) on an 
>> entry form
>> GREATLY enhances the ability/simplicity of tracking down data issues.
> 
> This same thing can also be done by adding the same field to the same 
> table but not linking off of it internally :)
> 
> 
> 
> --
> Neil Dennis
> 4D Developer since 1990
> 
> 
> GreaText - Designing Software for the Way You Work
> 716 East 1850 N
> North Ogden, UT 84414
> 
> mailto:npden...@greatext.com
> http://www.greatext.com/
> 
> 
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Preventing Duplicate Data WAS UUID vs Longint primary key

[Chip Scheide via 4D_Tech]

Jody,
what are your normal duplicate reducing/removal technic(s)?

On Mon, 7 Aug 2017 12:28:21 -0600, Jody Bevan via 4D_Tech wrote:
> John:
> 
> Thanks for sharing this. I had not thought of this way after all 
> these years. I will take the idea and apply where appropriate, in 
> addition to my normal code to reduce duplicates.
> 
> 
> Jody Bevan
> ARGUS Productions Inc.
> Developer
> 
> Argus Productions Inc. 
> 
> 
> 
> 
>> On Aug 7, 2017, at 11:50 AM, John Baughman via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> What I have done is to have a field in the table  that contains the 
>> keys that make the record unique with all spaces, special 
>> characters, and vowels removed, as well as eliminating any 
>> consecutive consonants . See my example below. So far this has 
>> worked pretty well for me and I guess would fall under David’s 
>> category of "Carefully program your system to detect and prevent 
>> duplicate rows”
>> 
>> John
>> 
>> ―― Example 
>> $firstName:=[Contacts]firstName (John)
>> $lastName:=[Contacts]lastName (Baughman)
>> $company:=[Contacts]company (BY’te DESIGN Hawwaii)  notice I have 
>> mistakenly put more than 1 w in Hawaii.
>> $DupeCheck:= $firstName+ $lastName+$company
>> [Contacts]DupeCheck:=AlphaOnlyNoVowels ($DupeCheck;"*”)  
>> //AlphaOnlyNoVowels does the heavy lifting. The asterisk tells the 
>> method to remove consecutive consonants.
>> 
>> [Contacts]DupeCheck now contains  “JHNBGHMNBYTDSGNHW”
>> 
>> I wrap the above in a duplicate checking method for the [Contacts] 
>> table called ContactsDuplicateManager
>> 
>> Whenever a record is updated or created in the Contacts table…
>> 
>> $DupeCheck:= ContactsDuplicateManager ("isDuplcate”;[Contacts]ID)
>> 
>> The ContactsDuplicate method creates the check string as above and 
>> searches the contacts table for duplicates using the 
>> [Contacts]DupeCheck field. If no duplicates are found it returns the 
>> check string. If a duplicate is found it returns the check string 
>> with a prepended asterisk.  The contact ID if passed prevents the 
>> dupe check from finding the record being updated. If this is a new 
>> record 0 is passed for the Contact ID. So…
>> 
>> If ($DupeCheck =“*@“
>>   Handle the duplicate in context. If, for example this is a user 
>> updating or creating a contact record, warn the user of the possible 
>> duplicate with available options.
>> 
>> else
>>   [Contacts]DupeCheck:=$DupeCheck
>>   SAVE RECORD([Contacts)
>> 
>> end if
>> 
>> -
>> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: ​Re: UUID vs Longint primary key

[Chip Scheide via 4D_Tech]

David,
how do you tell these two issues apart:
Customer name : John Smith
Customer Name : John Smyth

is this a typo (one should be Smyth and is not, or one should be Smith 
and is not)?
is it real (2 John Smiths with different spellings)

I see this problem with a 'free form' entry inventory data. i.e. the 
user can enter whatever in the item name/description field.

I do not see (for my inventory) a way to keep duplicate entries like:
Glove, latex, Medium
Medium Glove, latex
Latex glove size medium

yes, I can check part numbers, but... same glove from different 
suppliers can/will have different part numbers
ex: 
Joe's supply house: 12345
Fred's house of supplies: 56342-m

Worse, I've found that the same product, from the same vendor in 
differing purchase amounts (1 vs case) is the same part number, but 
different pricing! So.. even a check on part numbers is insufficient to 
stop duplicate entries.


I have setup a means for the users to remove duplicates, but of course 
they never do

always welcome a way to improve this situation
Chip

On Sun, 6 Aug 2017 13:06:28 -0700, David Adams via 4D_Tech wrote:
> Since I'm diving into Postgres these days (mostly on the import side - my
> table designs aren't even right yet - pacing myself), I see that they have
> a wide range of tools for enforcing row uniqueness and referential
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: ​Re: UUID vs Longint primary key

[npdennis via 4D_Tech]

> I find that by placing the internal linking value (non-editable) on an 
> entry form
> GREATLY enhances the ability/simplicity of tracking down data issues.

This same thing can also be done by adding the same field to the same table but 
not linking off of it internally :)



--
Neil Dennis
4D Developer since 1990


GreaText - Designing Software for the Way You Work
716 East 1850 N
North Ogden, UT 84414

mailto:npden...@greatext.com
http://www.greatext.com/


**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: ​Re: UUID vs Longint primary key

[Chip Scheide via 4D_Tech]

yes,
BUT -
I find that by placing the internal linking value (non-editable) on an 
entry form
GREATLY enhances the ability/simplicity of tracking down data issues.

ex (without viewable internal key):
user: "... customer John Smith does not show the correct invoice(s)
Dev/Sys admim: John Smith.. just a minute... hmm There are 43 John 
Smith's in the system, which one do you mean?
user: you know JOHN SMITH!
. [no need to continue  :) ]

ex: (with visible key):
user: "... customer John Smith does not show the correct invoice(s)
Dev/Sys admin: Can you please give me the number in the upper left hand 
corner, just below the screen title 'Customer Information'...
user:  1234567
Dev/Sys admin: just a moment... Ok got it. Now what is the exact 
problem
. [of course at this point getting the user to give useful 
information is next to impossible, but at least there is now a 
reference to the problem record/customer...]


On Sun, 6 Aug 2017 13:08:14 -0600, npdennis via 4D_Tech wrote:
> 
> On the other hand, you do model the data after business relations, 
> but the keys that tie that relation data need/should never be seen in 
> a well designed system. If a user readable key is needed by business, 
> then there should be another data piece that the user can read (like 
> an MRN, medical record number, or an abbreviation that is unique and 
> human readable) But these should never be used to link together data 
> in a structure in primary key foreign key relation.
> 
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

​Re: Preventing Duplicate Data REAL WORLD

[Jody Bevan via 4D_Tech]

I thought I would share this real world experience in regard to data, as it is 
somewhat humorous, but not for the people in the back seat.

Long long ago, in another country, I was a police member patrolling the 
downtown streets of a city in economic boom circumstances. There were lots and 
lots of young males from across the country in the city spending their money on 
things that too many young men spend their money on. As would be the case many 
of these young men would find themselves in the backseat of police cars all 
across the city.

As part of the process we needed to make a decision to release with a piece of 
paper OR haul down to jail.

Part of that process involved a search on the national criminal data base. We 
could have ID in front of us (i.e. Driver’s License), or they would just give 
us a name. The search would be performed based on name and date of birth. With 
frequent regularity there would be a hit of a warrant out for the person. Some 
were 50 mile radius (get out of town and don’t come back warrants from 1000 
miles away), or we want him back to face justice.

Of course we would ask - why did you lie to us. You have been in trouble, there 
are warrants for your arrest. The description matches close enough (eye colour, 
hair). Back then tattoos were not so popular so they were good identifiers. Of 
course they can be changed - so they would only give more confidence of a right 
identification.

Off to jail we would head, with our back seat occupant complaining that it is 
not him.

Check him in past the jail sgt. and away we go. We would find out after his 
finger prints were taken that he was telling the truth - it was not him.

This would happen with some regularity. In a country of (at that time of only 
24 million) I would have this happen about once a month, and there were 1100 
police in the city. 

So even data with the same name (First + Middle + Last) and same Date of Birth 
can correctly be different data when dealing with people. The records were not 
duplicates in looking at the finger print data, but back then (and even now) 
that is not something they can capture in the cars. Could they - yes but there 
are laws about taking people’s finger prints.

On a side note: 
A few years later I developed a photo ID lineup system that was rejected 
because it was written in house, and I wrote it on a Macintosh instead of 
MS-DOS. 


Jody Bevan
ARGUS Productions Inc.
Developer
Argus Productions Inc. 




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**