Re: subtables issue

[Keisuke Miyako via 4D_Tech]

the _o_ prefix is primarily telling you to stop using it in new code.

(you will no longer find it in type-ahead, for example)

it also allows you to find and remove them in existing code,
but the level of urgency varies;

some are not 64-bit ready,
some have a superior (preemptive, object based, simple...) successor,
some are just old-fashioned (require process or inter-process variables, 
pointers, etc.) and "not cool".

so you can't generalise all _o_ commands as if they were a liability.

---

as for sub-tables, ORDA completely changes how you look at related records.
they belong to a different table, or a data class, like in SQL,
but in code there are accessible as entities of the master table,
as if they were sub-fields or sub-sub-fields.

2018/11/04 6:29、Robert ListMail via 4D_Tech 
<4d_tech@lists.4d.com>のメール:
Are you suggesting that I leave the old “_o_” commands in place on a converted 
V17 database?


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

Re: subtables issue

[Robert ListMail via 4D_Tech]

Keisuke, can you elaborate on the potential ORDA approach in this situation…? 
I’m dealing with subtables as well in v17 and was about to eliminate the 
obsolete subtable/subrecord commands when I noticed that you mentioned leaving 
it alone….  Are you suggesting that I leave the old “_o_” commands in place on 
a converted V17 database?  For those of us wrapping our heads around ORDA, tell 
(please) how we can use the new 4D technology to resolve legacy subtable issues.

Thanks,

Robert

> On Jul 15, 2018, at 11:57 PM, Keisuke Miyako via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> you are already on v17,
> so the debate should be whether to stick with subtables or reengineer the 
> whole thing using ORDA.

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

Re: subtables issue

[Charles Miller via 4D_Tech]

Thanks to all. My issue is visual. I will check to see where the data is. I
have done this many times before but have never seen the subtable structure
remain

Regards


Chuck

On Mon, Jul 16, 2018 at 12:57 AM, Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> unless you were specifically asked to convert subtables,
> I think it would be best to not care about them and focus on converting
> pictures.
>
> as long as you keep the virtual subtable structure "as is" and never touch
> them,
> your subtable commands will continue to work in your methods
> and your list sub-tables will continue to display your sub-selections in
> your forms.
> (just make sure the data source table actually references your sub-table
> fields, not the real tables).
>
> transition from sub-tables to related tables take a lot of commitment,
> to replace commands one by one and modify forms one by one,
> and to finally "cut" the virtual subform link which is an irreversible
> procedure.
>
> the best outcome would be for you to end up where you started except you
> are using regular tables.
> the would be no practical value for the end user (other than may SQL
> connectivity to sub records import/export).
>
> you are already on v17,
> so the debate should be whether to stick with subtables or reengineer the
> whole thing using ORDA.
>
> 2018/07/16 8:40、Chuck Miller via 4D_Tech <4d_tech@lists.4d.com d_t...@lists.4d.com>>のメール:
>
> I have a situation I have not encountered and am stumped. I have been
> asked by a person to upgrade pictures in a v17 db. When I open the
> structure, I still see subtables there. I also see the tables that have
> been created as part of conversion. What gives? The new tables appear to be
> there. I am not sure what to do now.
>
>
>
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
>



-- 
-
 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)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: subtables issue

[Keisuke Miyako via 4D_Tech]

unless you were specifically asked to convert subtables,
I think it would be best to not care about them and focus on converting 
pictures.

as long as you keep the virtual subtable structure "as is" and never touch them,
your subtable commands will continue to work in your methods
and your list sub-tables will continue to display your sub-selections in your 
forms.
(just make sure the data source table actually references your sub-table 
fields, not the real tables).

transition from sub-tables to related tables take a lot of commitment,
to replace commands one by one and modify forms one by one,
and to finally "cut" the virtual subform link which is an irreversible 
procedure.

the best outcome would be for you to end up where you started except you are 
using regular tables.
the would be no practical value for the end user (other than may SQL 
connectivity to sub records import/export).

you are already on v17,
so the debate should be whether to stick with subtables or reengineer the whole 
thing using ORDA.

2018/07/16 8:40、Chuck Miller via 4D_Tech 
<4d_tech@lists.4d.com>のメール:

I have a situation I have not encountered and am stumped. I have been asked by 
a person to upgrade pictures in a v17 db. When I open the structure, I still 
see subtables there. I also see the tables that have been created as part of 
conversion. What gives? The new tables appear to be there. I am not sure what 
to do now.



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

Re: subtables issue

[Jeremy French via 4D_Tech]

Hi Chuck,

In answer to your several questions:


> ...When I open the structure, I still see subtables there. I also see the 
> tables that have been created as part of conversion. What gives? The new 
> tables appear to be there.

I believe 4D deprecated subtables starting with v11.

When converting from a pre-v11 version with subtables, 4D automatically creates 
a regular table in place of each subtable.

When creating the new regular table to replace the subtable, 4D's naming 
convention is “_”. Note the underscore 
character, separating the names of the parent table and subtable field.

All data from the original subtable is now located in the new regular table.


> I am not sure what to do now.

Complete the subtable conversion by replacing all obsolete subtable commands.

The value in the parent’s subtable field “History Detail" and converted 
subtable field “id_added_by_converter” are the same. That’s a unique Longint 
value that relates parent to its subtable data. 

Beware — you need to use the command “Get subrecord key” to access the parent’s 
subtable field’s value. I’m talking about the field "[Contract]History Detail”. 
That field is now a Longint, even though the structure editor shows “Subtable”. 
It’s value is how you will locate the “subrecords" which are now records in a 
regular table.

Subtable behavior will continue, as long as you don’t make any structure 
modifications to the original subtable field (in the parent table) and the 
“id_added_by_converter” field (in subtable that’s been converted to a regular 
table.)

You should replace all subtable commands (which are obsolete) and replace them 
with “regular” table commands.

I believe the command “Get subrecord key” will help navigate the relations 
until you complete the switch from subtable commands to regular table commands.

See: http://doc.4d.com/4Dv17/4D/17/Get-subrecord-key.301-3730628.en.html


> 
> For example I have a table named
> Contract with a subtable named History Detail
> 
> I also have a table named Contract_History Detail which has field named 
> id_added_by_converter.

The original subtable field “History Detail” is in the parent table “Contract”. 
That field’s type should appear as “Subtable”. Use the command “Get subrecord 
key” to access (or view) the “History Detail” field’s value, which is a longint.

All the subfield’s data has been moved to the new “Contract_History Detail” 
table. That’s the table with the field “id_added_by_converter”.

The subfield “History Detail” and the field “id_added_by_converter” in the new 
table “Contract_History Detail” form the relation between the data in the 
parent table (Contract) and the subtable’s data (Contract_History Detail).


> Can I just change type. why would I still be seeing this subtable the id 
> points back to the field in the Contract table

No, changing the field type will end the automatic subtable behavior. Wait 
until you complete the subtable conversion by replacing the obsolete subtable 
commands. Then decide how you would like to relate the records.

The subtable id that points back to the field in the Contract table preserves 
the relation between the parent record (Contract) and its subtable now located 
in a regular table (Contract_History Detail). They contain the same Longint 
value.

At the moment, the data value that binds the subtable records to the parent 
table is: the parent’s subtable field (“History Detail”) and the 
“id_added_by_converter” field in the new regular table “Contract_History 
Detail”. Both are Longints.

See: http://doc.4d.com/4Dv17/4D/17/Subrecords.201-3729374.en.html

Does this info help?

- Jeremy French

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

subtables issue

[Chuck Miller via 4D_Tech]

Hi All,

I have a situation I have not encountered and am stumped. I have been asked by 
a person to upgrade pictures in a v17 db. When I open the structure, I still 
see subtables there. I also see the tables that have been created as part of 
conversion. What gives? The new tables appear to be there. I am not sure what 
to do now.

For example I have a table named
Contract with a subtable named History Detail

I also have a table named Contract_History Detail which has field named 
id_added_by_converter.

Can I just change type. why would I still be seeing this subtable the id points 
back to the field in the Contract table

Thanks and regards

Chuck

 Chuck Miller Voice: (617) 739-0306
 Informed Solutions, Inc. Fax: (617) 232-1064   
 mailto:cjmillerinformed-solutions.com 
 Brookline, MA 02446 USA Registered 4D Developer
   Providers of 4D and Sybase 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)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**