Using listbox as output form replacement

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Using listbox as output form replacement

4D Tech mailing list
I have a form with a selection-based listbox which I use as an output form. In runtime mode, you just use DIALOG instead of DISPLAY SELECTION. If I set that form as the output form, it doesn’t work in User mode, it just says “There is no form selected to display the records of: [My_Table]”. Is there a way to get this to work in User mode?

Jim Crate

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

RE: Using listbox as output form replacement

4D Tech mailing list
Hi Jim,

> Is there a way to get this to work in User mode?

User Mode? Maybe the following items will help -

Tech Tip: User Mode is now a part of Design Mode
http://kb.4d.com/assetid=47243

Tech Tip: Converting Databases that used "User Mode"
http://kb.4d.com/assetid=75239

Tech Note: User Mode Component  (for databases prior to v12)
http://kb.4d.com/assetid=75777

Tech Tip: Virtual User Mode (for databases v12 and higher)
http://kb.4d.com/assetid=76942
https://github.com/miyako/4d-tips-virtual-user-mode

-Tim



**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Using listbox as output form replacement

4D Tech mailing list
On Oct 23, 2018, at 5:21 PM, Timothy Penner via 4D_Tech <[hidden email]> wrote:
>
> Hi Jim,
>
>> Is there a way to get this to work in User mode?
>
> User Mode? Maybe the following items will help -
>
> Tech Tip: User Mode is now a part of Design Mode
> http://kb.4d.com/assetid=47243

I don’t really need any old User mode functionality. So I’ll re-phrase: a normal output form with header, detail, footer sections displays properly in the Design mode window that displays the form with data. A form using a listbox for the detail section does not seem to display properly.

I have figured out that if the detail area specified by the form markers is not zero, the form displays. The listbox displays fine in the header or footer. However, I’m not sure where to put the markers so that the listbox will take up the available space, like a regular listing. It works well enough, I suppose, if I move the markers down far enough for the header to take up the space that I use for that window.

Jim Crate

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Using listbox as output form replacement

4D Tech mailing list
On Oct 23, 2018, at 5:37 PM, Jim Crate via 4D_Tech <[hidden email]> wrote:

>
> On Oct 23, 2018, at 5:21 PM, Timothy Penner via 4D_Tech <[hidden email]> wrote:
>>
>> Hi Jim,
>>
>>> Is there a way to get this to work in User mode?
>>
>> User Mode? Maybe the following items will help -
>>
>> Tech Tip: User Mode is now a part of Design Mode
>> http://kb.4d.com/assetid=47243
>
> I don’t really need any old User mode functionality. So I’ll re-phrase: a normal output form with header, detail, footer sections displays properly in the Design mode window that displays the form with data. A form using a listbox for the detail section does not seem to display properly.
>
> I have figured out that if the detail area specified by the form markers is not zero, the form displays. The listbox displays fine in the header or footer. However, I’m not sure where to put the markers so that the listbox will take up the available space, like a regular listing. It works well enough, I suppose, if I move the markers down far enough for the header to take up the space that I use for that window.

Actually the listbox growth properties aren’t respected, so the listbox also has to take up the space. I didn’t notice that moving the marker resized my listbox.

Anyway, close enough, I suppose. Setting it up like that doesn’t affect the display using the DIALOG command.

Jim Crate

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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 ‘primary key’ flag from all the ID fields, then I need to add UID fields to every table,
change the foreign keys as well, and use apply formula to make sure the relations are intact. I am a bit worried that this will have a major impact on the size of the data file.

Furthermore, I need to automate the whole process so the upgrade works flawlessly at the customers site.

Has anyone ever done this?
Any tips?

Regards,

Rudy Mortier
Two Way Communications bvba

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Using listbox as output form replacement

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Hi Jim,

No, this will not work in user mode. To use a listbox in that way (generic), you need to put it in an input form, to start with. You can only use it by programming, using DIALOG.

Regards,

Rudy Mortier
Two Way Communications bvba



> On 24 Oct 2018, at 02:13, Jim Crate via 4D_Tech <[hidden email]> wrote:
>
> I have a form with a selection-based listbox which I use as an output form. In runtime mode, you just use DIALOG instead of DISPLAY SELECTION. If I set that form as the output form, it doesn’t work in User mode, it just says “There is no form selected to display the records of: [My_Table]”. Is there a way to get this to work in User mode?
>
> Jim Crate
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Using listbox as output form replacement

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Hi Jim,
I have a couple of thoughts about this. First, for user mode output forms I
stick with plain, old 4D output forms. It's really the best.

Second, I totally support the direction you're going with using a Dialog
and a listbox instead of MODIFY/DISPLAY SELECTION. I would encourage you to
try doing this with arrays instead of selections though. Here are some
reasons I've come to favor this which I'll preface by saying for years I've
been working on a C/S db that's accessed by clients via HTTP so optimizing
transfer rates has been particularly important to me. Also if you do have a
table with lots and lots of fields you likely want to show (or let the user
pick) a smaller selection that's useful in a list. I'm not one who likes to
show listboxes with more than about 20 columns and rarely that many.

Selections can involve a lot more data: when you display a record as part
of a selection 4D moves the entire record from the server to the client.
That can be a lot of data. This can be optimized using the 'store outside
of datafile' option on blobs, text and so forth (which is what that is
really for I believe). So if you are displaying 8 or 10 fields of a record
with dozens or hundreds of fields there's a lot of extra transfer you don't
need.

You have fewer record locking issues: your display form/process can be read
only. Open records for detail viewing/editing in a separate process window
and manage the read/write issues there.

Array operations are fast: Both loading and working with arrays is very
quick. Years ago having enough memory for large selections could have been
an issue but not so much today.

User interactions are faster: there's rarely a comparison between how fast
an array based listbox can respond vs. a selection based one if you've got
a selection of any size.

Use an object array if you can.


My general workflow is:

user inputs some query criteria
send this to the server (execute on server method) to do the query and
return the arrays.


If I am using an object array I populate it with objects containing the
relevant data for each record.
If I'm using arrays I pass pointers to the arrays to the query method.
In both cases you can get a performance boost by declaring local arrays you
need in the query method and use COPY ARRAY to populate the return objects.


On Tue, Oct 23, 2018 at 5:14 PM Jim Crate via 4D_Tech <[hidden email]>
wrote:

> I have a form with a selection-based listbox which I use as an output
> form. In runtime mode, you just use DIALOG instead of DISPLAY SELECTION. If
> I set that form as the output form, it doesn’t work in User mode, it just
> says “There is no form selected to display the records of: [My_Table]”. Is
> there a way to get this to work in User mode?
>

--
Kirk Brooks
San Francisco, CA
=======================

*We go vote - they go home*
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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 <
[hidden email]> wrote:

> 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
> ‘primary key’ flag from all the ID fields, then I need to add UID fields to
> every table,
> change the foreign keys as well, and use apply formula to make sure the
> relations are intact. I am a bit worried that this will have a major impact
> on the size of the data file.
>
> Furthermore, I need to automate the whole process so the upgrade works
> flawlessly at the customers site.
>
> Has anyone ever done this?
> Any tips?
>
> Regards,
>
> Rudy Mortier
> Two Way Communications bvba
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************

--
-----------------------------------------------------------------------------------------
 Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064
 Informed Solutions, Inc.
 Brookline, MA 02446 USA Registered 4D Developer
       Providers of 4D, Sybase & SQL Server connectivity
          http://www.informed-solutions.com
-----------------------------------------------------------------------------------------
This message and any attached documents contain information which may be
confidential, subject to privilege or exempt from disclosure under
applicable law.  These materials are intended only for the use of the
intended recipient. If you are not the intended recipient of this
transmission, you are hereby notified that any distribution, disclosure,
printing, copying, storage, modification or the taking of any action in
reliance upon this transmission is strictly prohibited.  Delivery of this
message to any person other than the intended recipient shall not
compromise or waive such confidentiality, privilege or exemption
from disclosure as to this communication.
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
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 <[hidden email]> wrote:
>
> 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 <
> [hidden email]> wrote:
>
>> 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
>> ‘primary key’ flag from all the ID fields, then I need to add UID fields to
>> every table,
>> change the foreign keys as well, and use apply formula to make sure the
>> relations are intact. I am a bit worried that this will have a major impact
>> on the size of the data file.
>>
>> Furthermore, I need to automate the whole process so the upgrade works
>> flawlessly at the customers site.
>>
>> Has anyone ever done this?
>> Any tips?
>>
>> Regards,
>>
>> Rudy Mortier
>> Two Way Communications bvba
>>
>>

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
No it isn't.

> On Oct 24, 2018, at 11:59 AM, Keith Culotta via 4D_Tech <[hidden email]> wrote:
>
> Is using them to link between tables (establish 4D Relations, correct?) a hazardous practice?

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
[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 <[hidden email]> wrote:
>
> No it isn't.
>
>> On Oct 24, 2018, at 11:59 AM, Keith Culotta via 4D_Tech <[hidden email]> wrote:
>>
>> Is using them to link between tables (establish 4D Relations, correct?) a hazardous practice?
>

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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
exist and are inplace as requested/required?


On Wed, 24 Oct 2018 10:59:48 -0500, Keith Culotta via 4D_Tech wrote:

> 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
>> <[hidden email]> wrote:
>>
>> 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 <
>> [hidden email]> wrote:
>>
>>> 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
>>> ‘primary key’ flag from all the ID fields, then I need to add UID
>>> fields to
>>> every table,
>>> change the foreign keys as well, and use apply formula to make sure the
>>> relations are intact. I am a bit worried that this will have a
>>> major impact
>>> on the size of the data file.
>>>
>>> Furthermore, I need to automate the whole process so the upgrade works
>>> flawlessly at the customers site.
>>>
>>> Has anyone ever done this?
>>> Any tips?
>>>
>>> Regards,
>>>
>>> Rudy Mortier
>>> Two Way Communications bvba
>>>
>>>
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************
---------------
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
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 will never work with LONGINT ids and foreign keys …

Another example is replication. My users, most of the time, are working client-server. But often, they need a part of the datafile as a local database on their laptop, so I need to replicate at least a part of
the data into a stand-alone database. Then, if they add records to the local database, I want to replicate that new information back to the server database.

The only way this would be possible is to change all the LONGINT ids to UUID, and also the foreign keys ….

Regards,

Rudy Mortier
Two Way Communications bvba



> On 24 Oct 2018, at 18:16, Chip Scheide via 4D_Tech <[hidden email]> wrote:
>
> 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
> exist and are inplace as requested/required?
>
>
> On Wed, 24 Oct 2018 10:59:48 -0500, Keith Culotta via 4D_Tech wrote:
>> 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
>>> <[hidden email]> wrote:
>>>
>>> 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 <
>>> [hidden email]> wrote:
>>>
>>>> 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
>>>> ‘primary key’ flag from all the ID fields, then I need to add UID
>>>> fields to
>>>> every table,
>>>> change the foreign keys as well, and use apply formula to make sure the
>>>> relations are intact. I am a bit worried that this will have a
>>>> major impact
>>>> on the size of the data file.
>>>>
>>>> Furthermore, I need to automate the whole process so the upgrade works
>>>> flawlessly at the customers site.
>>>>
>>>> Has anyone ever done this?
>>>> Any tips?
>>>>
>>>> Regards,
>>>>
>>>> Rudy Mortier
>>>> Two Way Communications bvba
>>>>
>>>>
>>
>> **********************************************************************
>> 4D Internet Users Group (4D iNUG)
>> Archive:  http://lists.4d.com/archives.html
>> Options: https://lists.4d.com/mailman/options/4d_tech
>> Unsub:  mailto:[hidden email]
>> **********************************************************************
> ---------------
> Gas is for washing parts
> Alcohol is for drinkin'
> Nitromethane is for racing
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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
 b) at the same time remove the old relations & draw in the new ones
 c) write a conversion method(s) to loop through all affected records
   i) lookup the linked records based on the old longint field
  ii) set the new UUID foreign key
 d) update all the queries that relied on the old key fields

Personally I'd retain the old longint fields and keep incrementing them
though in most cases I'd drop the indexes. The reason being it's useful to
have a user-readable serial number that isn't an actual 'key field' but is
unique enough to be useful doing ad hoc queries and debugging. It will also
prevent any direct queries on it from failing though they will get slow
(and identifiable) if you dropped the index. Queries that relied on the
relations will fail and also be easy to spot.

On Wed, Oct 24, 2018 at 7:52 AM Two Way Communications via 4D_Tech <
[hidden email]> wrote:

> 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.
>
--
Kirk Brooks
San Francisco, CA
=======================

*We go vote - they go home*
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

RE: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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 addressee. If you are not the named addressee you should not disseminate, distribute or copy this email. Please delete this email from your system and notify the sender immediately by replying to this email.  If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

The Alternative Investments division of UMB Fund Services provides a full range of services to hedge funds, funds of funds and private equity funds.  Any tax advice in this communication is not intended to be used, and cannot be used, by a client or any other person or entity for the purpose of (a) avoiding penalties that may be imposed on any taxpayer or (b) promoting, marketing, or recommending to another party any matter addressed herein.
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

RE: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list

>- 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 requested/required?

Do I ever want to have a user ever know anything about or see a primary or foreign key anyway 😊

Neil






--



Privacy Disclaimer: This message contains confidential information and is intended only for the named addressee. If you are not the named addressee you should not disseminate, distribute or copy this email. Please delete this email from your system and notify the sender immediately by replying to this email.  If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

The Alternative Investments division of UMB Fund Services provides a full range of services to hedge funds, funds of funds and private equity funds.  Any tax advice in this communication is not intended to be used, and cannot be used, by a client or any other person or entity for the purpose of (a) avoiding penalties that may be imposed on any taxpayer or (b) promoting, marketing, or recommending to another party any matter addressed herein.
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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.

John Baughman
Kailua, Hawaii
[hidden email]

On Oct 24, 2018, at 5:49 AM, Charles Miller via 4D_Tech <[hidden email]> wrote:

>> Now, for replication and sharing purposes, I would like to change the type
>> to UID.
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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 doesn't mean it's a
good idea to use it as a key. Social Security numbers are the perfect
example of this.

Another instance is being able to identify records any place in the
database by a single value. For instance, I have a table for recording
notes users attach to records. The idea it to be able to attach a note to
anything. If I'm using longints it takes two fields to identify the record,
table # & id #. With a UUID I only need one.

Another instance in my history was the necessity to merge data from two
tables into one as part of a refactoring. This was tricky because there was
duplication of IDs in the series and lots of linked records as well. If
they'd been UUIDs it would have been a non-issue. Same thing for syncing
data from distributed databases.

Another instance that comes to mind is troubleshooting new datafiles.
Client has a production database that allows users to create multiple
datafiles. (True story.) There's some issue that's only shows up creating
new datafiles. Using long ints all the tables are starting their sequences
at 1. Have a complex linking situation where a linking table with 4 fields
pointing at different related tables all have the same values in all
fields.

I think a lot of 4D issues arise from how easy it is to conflate the data
with structure. UUIDs are way to separate them and I think leads to more
robust structure designs.

On Wed, Oct 24, 2018 at 9:17 AM Chip Scheide via 4D_Tech <
[hidden email]> wrote:

> 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
> exist and are inplace as requested/required?
>
>
> On Wed, 24 Oct 2018 10:59:48 -0500, Keith Culotta via 4D_Tech wrote:
> > 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
> >> <[hidden email]> wrote:
> >>
> >> 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 <
> >> [hidden email]> wrote:
> >>
> >>> 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
> >>> ‘primary key’ flag from all the ID fields, then I need to add UID
> >>> fields to
> >>> every table,
> >>> change the foreign keys as well, and use apply formula to make sure the
> >>> relations are intact. I am a bit worried that this will have a
> >>> major impact
> >>> on the size of the data file.
> >>>
> >>> Furthermore, I need to automate the whole process so the upgrade works
> >>> flawlessly at the customers site.
> >>>
> >>> Has anyone ever done this?
> >>> Any tips?
> >>>
> >>> Regards,
> >>>
> >>> Rudy Mortier
> >>> Two Way Communications bvba
> >>>
> >>>
> >
> > **********************************************************************
> > 4D Internet Users Group (4D iNUG)
> > Archive:  http://lists.4d.com/archives.html
> > Options: https://lists.4d.com/mailman/options/4d_tech
> > Unsub:  mailto:[hidden email]
> > **********************************************************************
> ---------------
> Gas is for washing parts
> Alcohol is for drinkin'
> Nitromethane is for racing
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************



--
Kirk Brooks
San Francisco, CA
=======================

*We go vote - they go home*
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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 converted, for each related field it
  remembers the longint value in the One Table's field
  creates and saves a UUID for the One Table's field
  queries the related using the old longint value
  changes the Many table's link field to the One Table's UUID.
  set the relations and Primary Keys*

Eventually marks the datafile as converted.

*Can SQL be used to set a Primary Key for a table that has none?

Keith - CDI

> On Oct 24, 2018, at 9:52 AM, Two Way Communications via 4D_Tech <[hidden email]> wrote:
>
> 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 ‘primary key’ flag from all the ID fields, then I need to add UID fields to every table,
> change the foreign keys as well, and use apply formula to make sure the relations are intact. I am a bit worried that this will have a major impact on the size of the data file.
>
> Furthermore, I need to automate the whole process so the upgrade works flawlessly at the customers site.
>
> Has anyone ever done this?
> Any tips?
>
> Regards,
>
> Rudy Mortier
> Two Way Communications bvba
 
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Longing IDs or UUIDs as primary key?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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 longint ID (relational field(s)),
this gives each record unique relational ID(s) in each database in
which that data resides.
   -- assign these new relational ID(s) to the relational field(s) of
other imported records

no need to redraw, no need to convert, no need to change existing
working code.

On Wed, 24 Oct 2018 09:37:08 -0700, Kirk Brooks via 4D_Tech wrote:
>
>  a) go through every table affected and add the UUID field
>  b) at the same time remove the old relations & draw in the new ones
>  c) write a conversion method(s) to loop through all affected records
>    i) lookup the linked records based on the old longint field
>   ii) set the new UUID foreign key
>  d) update all the queries that relied on the old key fields
---------------
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
12