Thanks to all of you for the valuable insights. Seems I’ve got some work to do
;-)
Regards,
Rudy Mortier
Two Way Communications bvba
> On 24 Oct 2018, at 19:17, Chuck Miller via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> No it is just painful let’s assume for some reason record in a many
It’s a setting in the properties of the listbox column
Rudy Mortier
Two Way Communications bvba
> On 25 Oct 2018, at 04:47, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> how do you do this?
>
>
>> In 4D list boxes, a column can be set up to show an ellipsis in the
>>
how do you do this?
> In 4D list boxes, a column can be set up to show an ellipsis in the
> middle of a string (instead of the end) when a column is too small.
> This is perfect for UUID columns. Just make them wide enough to only
> show the first and last 3 characters. Just as easy as a
> On 24 Oct 2018, at 16:52, Two Way Communications via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> The process seems quite cumbersome: to start, I need to remove the ‘primary
> key’ flag from all the ID fields
Rudy -
Just to add to the many useful contributions made so far, I found a way to
I've heard lots of comments over the years talking about how hard it is to work
with UUIDs. I’d like to offer a different perspective. I switched to UUIDs from
longints for primary keys 7 or 8 years ago. It took some careful programming to
migrate the datafiles in place, but it was _so_ worth
Sorry, forgot the UUID properties would still have to be set for the fields
after all that. Again, SQL?
Name it the "No way, YOU click the 'OK to Update' button" method.
> On Oct 24, 2018, at 12:01 PM, Keith Culotta via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> Here's a possible approach to
No it is just painful let’s assume for some reason record in a many table where
assigns to wrong main table which would you rather type in to fix 145764 or a
32 character UUID
In my opinion the journal aspect should have been hidden by 4D and the UUID
field should have been there but hidden
Kirk,
I am not suggesting using SS numbers, or anything the user can
change/touch as a linking value.
a longint (or other sequential value [text] - like a license plate)
generated for each new record for each table which is used explicitly
for identifying the record and possibly linking
I and Admin(s) may need to see/work with the relational key to attempt
to determine why/if something is F-ed.
off the top of my head scenario:
invoice does not show expected line items.
-(for me) first step examine raw data to see if the 'missing' line
item(s) exist.
-- to do this you need to
There are other options which may be more attractive if you are willing to put
more work in your synchronization code. I did something like this years ago
before UUIDs existed. You need to be able to identify shared records (which can
be a UUID field without it being the primary key) and then
why not:
- Add UUID as needed.
- populate
Using Send/receive record
during synchronization
repeat for each record to import
- read the record to import
- verify the UUID of the imported record
- if it exists
-- do whatever record merging you need
- if it does not exist, assign a NEW
Here's a possible approach to automating, but it depends last question.
If you change a longint to an alpha field, the new new alpha field retains the
longint value.
You could send the modified Structure with the longint fields changed to alpha.
When the Structure sees that a Datafile is not
Hi Chip,
Another way to look at this is in terms of separating the logical structure
from the data. Using UUIDs compels you to think about the logical structure
separately from the contents. That's a good thing. I agree it can be useful
to have a unique serial number on some tables. But that
It made no sense to me to abandon my longint primary keys used for relational
integrity and uniqueness in a long standing system when 4D would automatically
establish and maintain a new UUID primary key for the purposes of replication
and sharing right along side my working longint field.
>- Do I **really** want to type a UUID to try to follow/check on related
>records when something goes pear-shaped?
>- Do I want my admin(s) to have to type a UUID to try to chase related records?
>- Do I want to have to work with UUIDs, other then knowing that they exist and
>are inplace as
I use UUID for links between tables, I wouldn't ever go back to longint keys.
They are faster than sequential keys in a lot of respects (long discussion)...
I love them.
Neil
--
Privacy Disclaimer: This message contains confidential information and is
intended only for the named
Rudy,
I did something similar once, partly to see how hard it would be. I would
not race into doing it again unless there was some really compelling
reason.
Assuming there is that compelling reason the process worked something like
this:
a) go through every table affected and add the UUID field
To be clearer on the purpose:
There are many customers who use my application.
What I want to achieve is that they can ’share’ data. In order to do that, I
really do need a UUID, because I intend to exchange the records (and related
records) between their individual databases.
Obviously this
it is more of a situation of:
- Do I **really** want to type a UUID to try to follow/check on
related records when something goes pear-shaped?
- Do I want my admin(s) to have to type a UUID to try to chase related
records?
- Do I want to have to work with UUIDs, other then knowing that they
[some emoji that expresses a slight sense of relief, but not necessarily a
feeling of being surprised]
> On Oct 24, 2018, at 11:01 AM, Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> No it isn't.
>
>> On Oct 24, 2018, at 11:59 AM, Keith Culotta via 4D_Tech
>>
No it isn't.
> On Oct 24, 2018, at 11:59 AM, Keith Culotta via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> Is using them to link between tables (establish 4D Relations, correct?) a
> hazardous practice?
**
4D Internet Users
RE: never use them to link between tables
Is using them to link between tables (establish 4D Relations, correct?) a
hazardous practice?
Thanks,
Keith - CDI
> On Oct 24, 2018, at 10:49 AM, Charles Miller via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> Rudy
>
> For me this always choose UUID
Rudy
For me this always choose UUID for primary key and never use them to link
between tables. The overhead from space is not so great Andy I never want
to type in uuid to find related records etc
Regards
Chuck
On Wed, Oct 24, 2018 at 10:52 AM Two Way Communications via 4D_Tech <
I have an application with a big database file ( + 60 GB), with 128 tables. (4D
v17)
All id fields and foreign keys are of type longint.
Now, for replication and sharing purposes, I would like to change the type to
UID.
The process seems quite cumbersome: to start, I need to remove the
24 matches
Mail list logo
