<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://communities.bentley.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Import Overwrite Options Issue</title><link>https://communities.bentley.com/products/geotechnical1/f/geotechnical-forum/238193/import-overwrite-options-issue</link><description>I am working with a template provided by another person. I create a new project using that template. All looks empty and pretty standard. I do an import of my source data using the &amp;quot;Named Fields&amp;quot; option, and get the following log with the indicated Warnings</description><dc:language>en-US</dc:language><generator>Telligent Community 12</generator><item><title>RE: Import Overwrite Options Issue</title><link>https://communities.bentley.com/thread/742288?ContentTypeID=1</link><pubDate>Fri, 18 Nov 2022 18:23:32 GMT</pubDate><guid isPermaLink="false">6dad98f5-dbc9-4c4d-a9ba-e9da8dc6aa8e:681295c9-8599-4c14-88cb-19aef1124a5e</guid><dc:creator>Art Koenig</dc:creator><description>&lt;p&gt;I have done some more digging, and it seems that some of the relations in the offending template are &amp;ldquo;off&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;Specifically these table relations:&lt;/p&gt;
&lt;p&gt;Table Lab Specimen and Table Atterberg&lt;br /&gt; Table Lab Specimen and Table Sieve&lt;br /&gt; Table Lab Specimen and Table Wc Density&lt;/p&gt;
&lt;p&gt;By off, for example, take the Table Lab Specimen Table Atterberg relation. (Image attached) In the offending template, the relationship-line termination symbol in the MSAccess display of Table Relations, shows a one-to-many relation, whereas on clicking the relationship line, and then right clicking to Edit Relationship, the Edit Relationships dialog says one-to-one.&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;I took a look at the &amp;ldquo;gint std us lab.gdt&amp;rdquo;, and the relations symbols there match the Edit Relations Dialog. The MS Access Table Relations graphic says one-to-one on the Lab Specimen to Atterberg relation, and the Edit Relations dialog also says one-to-one. (See attached screen grabs.)&lt;/p&gt;
&lt;p&gt;Imports go fine against projects created from the &amp;ldquo;gint std us lab.gdt&amp;rdquo;, and also go fine against projects created from other templates from other companies, but not this one client, and I suspect that somehow their template got mis-configured, and that they do not do any imports that fire the issue.&lt;/p&gt;
&lt;p&gt;I note that on projects made off the offending template, not only does the &amp;ldquo;Data Sets&amp;rdquo; overwrite option make things go crazy, but that on doing an import, and then editing (for example, editing a Wc Wet Weight), and then doing a re-import, using the Named Fields option, the changed data does not get replaced by the source data, but stays the same.&lt;/p&gt;
&lt;p&gt;If one does the same import against a &amp;ldquo;gint std us lab.gdt&amp;rdquo; project, all works as expected, and the source data overwrites that changed Wc Wet Weight.&lt;/p&gt;
&lt;p&gt;Go figure&lt;/p&gt;
&lt;p&gt;In summary it looks to me like somehow their data structures got laid up incorrectly, or that somehow the template got corrupted. BTW- a DB repair compact does not resolve the issue.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;My Solution:&lt;/strong&gt; I deleted the existing relation between:&lt;/p&gt;
&lt;p&gt;Table Lab Specimen and Table Atterberg&lt;br /&gt;Table Lab Specimen and Table Sieve&lt;br /&gt;Table Lab Specimen and Table Wc Density&lt;/p&gt;
&lt;p&gt;and then recreated them. On the creation they get laid in properly as one-to-one, both as to the line termination icons and in the Edit Relations dialog. After this the import works as expected.&lt;/p&gt;
&lt;p&gt;Go Figure!&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;img alt=" " src="/resized-image/__size/320x240/__key/communityserver-discussions-components-files/283906/2022_2D00_11_2D00_13_5F00_12_2D00_26_2D00_14.png" /&gt;&lt;img alt=" " src="/resized-image/__size/320x240/__key/communityserver-discussions-components-files/283906/2022_2D00_11_2D00_13_5F00_12_2D00_30_2D00_24.png" /&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Import Overwrite Options Issue</title><link>https://communities.bentley.com/thread/742099?ContentTypeID=1</link><pubDate>Thu, 17 Nov 2022 16:28:04 GMT</pubDate><guid isPermaLink="false">6dad98f5-dbc9-4c4d-a9ba-e9da8dc6aa8e:dca6bbd2-bfd0-45ec-ba76-02298874d9d3</guid><dc:creator>Art Koenig</dc:creator><description>&lt;p&gt;YES -- My testing indicate this is on the right track. I have done some more sleuthing and will have follow-up with results in a bit.&lt;br /&gt;&lt;br /&gt;In the meantime, you say...&amp;nbsp;&lt;br /&gt;&lt;br /&gt;&lt;em&gt;&amp;nbsp;but checking the allow duplicate keys option in the data structure causes gINT/Access to add a hidden index to keep the duplicate records distinct.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Re: That hidden index - I am seeming to remember somewhere reading that the underlying source database of gINT (the .gpj file itself) is MS Access, and that when the database connection is made, that gINT creates a temporary database, and that the temporary database is what gINT is working with on a primary level. With this, I am thinking that on reading the underlying .gpj file into the temporary database, that these hidden counters are added. i.e., That the counters are added into the database that gINT is using as the intermediary.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;#1&amp;nbsp;&lt;/strong&gt; &amp;nbsp;Is this correct about the creation of&amp;nbsp; temporary database, and also about the insertion of the &amp;quot;hidden&amp;quot; counters into&lt;span style="text-decoration:underline;"&gt; that&lt;/span&gt; database?? On inspection in Access, these &amp;quot;hidden counters&amp;quot; are not in the underlying .gpj ( MS Access) file.&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;#2&lt;/strong&gt;&amp;nbsp; &amp;nbsp;When the file is saved, and the original access database did NOT have the Indexed property set to&amp;nbsp; &amp;quot;duplicates allowed&amp;quot; ( when you look at it in MS Access), on the save, AND if in gINT one selects the &amp;quot;Allow Duplicates&amp;quot; option,&amp;nbsp; does gINT modify that &amp;quot;Indexed&amp;quot; setting in the foundational .gpj? ie if one looks at the underlying original access DB, will they find that the settings for the Indexed Property of the field(s) have changed.&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;#3&amp;nbsp;&lt;/strong&gt; If it does modify the indexed setting, will it modify the underlying &amp;quot;Join(s)&amp;quot;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Import Overwrite Options Issue</title><link>https://communities.bentley.com/thread/741953?ContentTypeID=1</link><pubDate>Thu, 17 Nov 2022 03:59:15 GMT</pubDate><guid isPermaLink="false">6dad98f5-dbc9-4c4d-a9ba-e9da8dc6aa8e:2f700422-e1b8-44f6-a918-098886c393bc</guid><dc:creator>szang</dc:creator><description>&lt;p&gt;Don&amp;#39;t know if I know the answer but I will add some comments/sugestions that might help. This is my understanding and I would encourage others to correct/ add to my discussion&lt;/p&gt;
&lt;p&gt;For your question a.&amp;nbsp; what is happening is that the tables in question are set to allow duplicate record keys. For example, if the keyset for a table is PoitID, depth you are allowed to enter more than one record with the same pointID and depth. Suppose your table for atterburg had the following fields&lt;/p&gt;
&lt;p&gt;PointID, depth, LL, PL&lt;/p&gt;
&lt;p&gt;if you had 2 results at the same depth, you could enter&lt;/p&gt;
&lt;p&gt;B-1, 10.3, 32, 23&lt;/p&gt;
&lt;p&gt;B-1, 10.3, 67, 42&lt;/p&gt;
&lt;p&gt;This would normally not be permitted because you have 2 records with the same key but checking the allow duplicate keys option in the data structure causes gINT/Access to add a hidden index to keep the duplicate records distinct.&amp;nbsp; The problem comes when you try to reimport revised data. In this case gINT doesn&amp;#39;t know which record to assign the changed record to and refuses to do it unless you overwrite the entire dataset. this essentially deletes the existing records and imports the correct records.&amp;nbsp; it also deletes parent records and any other data you may have added to the data set in gINT as well so if you have made changes to those in gint they will be lost when you reimport.&lt;/p&gt;
&lt;p&gt;For your question b. in my limited testing i was able to import records with duplicate keys into tables that allowed duplicate keys and it comes in fine with both records intact.&amp;nbsp; I do get the warning message.&amp;nbsp; If I try to reimport revised data it refuses to import the revised data unless I use the overwrite data sets option as described above. this wipes out any other changes I may have made in gINT as expected. not sure why you are not able to do the same. could be a version issue as you noted so i would try opening the data template (.gdt) in your current gint and resaving it. then create a new project using the resaved data template and see if it functions as expected.&amp;nbsp; Ultimate solution is to either not allow duplicate keys or to not maintain 2 completely different data sets while allowing changes to be made to either one. sort of like having 2 copies of the same report in 2 word documents and allowing 2 people to work on&amp;nbsp;their copy independently. When it comes time to assemble the final report you have a hot mess on your hands as the same section may have been modified in 2 different ways. It requires that you carefully track what changes you have made in each document, when those changes were made and only merge carefully selected parts of the data&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>