Re: About using the same data file in two different structures...

Thanks again Tim. I actually proved this to myself yesterday with a couple of test databases and found exactly this situation. On Mon, Dec 5, 2016 at 11:56 AM, Timothy Penner wrote: > Hi Kirk, > > > What I'm seeing is the table names don't seem to matter as long as the > Tables

RE: About using the same data file in two different structures...

Hi Kirk, > What I'm seeing is the table names don't seem to matter as long as the Tables > and Fields have exactly the same numbers. Please see here: http://kb.4d.com/assetid=76862 I hope this helps, -Tim PENNER ** 4D

Re: ​About using the same data file in two different structures...

Hi Chip, That is an interesting idea. It's overkill in this case though. The basic idea is that the Main database is the one actually doing all the work and the Satellites are just doing queries and displaying results. So it's not actually a mirror so much as a reflection, to get a little Platonic

Re: ​About using the same data file in two different structures...

Kirk, I haven't seen anyone mentioning this.. As I remember (I do not work with remote sites, so grain of salt..) - You can turn on data logging (backup) which creates a journal file that can be used to update a database in case of crash and data loss. - You can save these files, and pass them to

Re: ​About using the same data file in two different structures...

Steve, Once more I really want to thank you for taking the time to lay so much of your process out. I agree about the export/import issues with records in a proprietary format. I much prefer nice, editable text files as well. I also agree about the benefits of a UUID as a key field. I'm starting

Re: About using the same data file in two different structures...

Hi Tim, Thanks for this. And explains why the .match file gets stashed in the Logs folder. On Sun, Dec 4, 2016 at 5:08 PM, Tim Nevels wrote: > On Dec 4, 2016, at 12:36 PM, Kirk Brooks wrote: > > > Miyako, > > Playing with your UUID tool clarified how the data file and

Re: ​About using the same data file in two different structures...

On Sun, Dec 4, 2016 at 1:36 PM, ​ ​ Kirk Brooks wrote: > > Hi Steve, > Thanks very much for posting this. It's exactly the kind of real-world > experience I was hoping to hear. > A couple of questions that come to mind: > So for the exporting it sounds like you're using the

Re: About using the same data file in two different structures...

On Dec 4, 2016, at 12:36 PM, Kirk Brooks wrote: > Miyako, > Playing with your UUID tool clarified how the data file and structure file > correspond with each other. > > And Spencer's comment about the table UUID clarifies things further. > > With regard to the .match file - is the file simply a

Re: About using the same data file in two different structures...

Miyako, Playing with your UUID tool clarified how the data file and structure file correspond with each other. And Spencer's comment about the table UUID clarifies things further. With regard to the .match file - is the file simply a list of the internal UUIDs assigned to tables? Which is to

Re: About using the same data file in two different structures...

Spencer, Thank you. I think this is going to prove to be a very valuable insight for us. On Sat, Dec 3, 2016 at 5:49 PM, Spencer Hinsdale wrote: > Do either matter? I kinda think MyStructure.Match is the map of table > UUIDs. My guess is that if you have two identical

Re: About using the same data file in two different structures...

David, On Sat, Dec 3, 2016 at 5:17 PM, David Adams wrote: > Back in the olden days, you could open any 4D data > file by creating a 255 table 255 field structure with all text fields. > Hence the WEDD file...and isn't there a feature now to block opening a > mis-matched

Re: About using the same data file in two different structures...

that is right, you can confirm in a single database. create a table add some records delete the table create a new table (which will be given the same number as the old deleted table) the records are NOT restored it makes no difference (unless you use SQL) if the table has the same name,

Re: About using the same data file in two different structures...

that's right, structure and data UUIDs replace the old WEDD resource (which I consider to be a fantastic resource name...) https://github.com/miyako/4d-utility-uuid-manager > 2016/12/04 10:17、David Adams のメール： > Hence the WEDD file...and isn't there a feature now to block

Re: About using the same data file in two different structures...

Do either matter? I kinda think MyStructure.Match is the map of table UUIDs. My guess is that if you have two identical structures and add a new table to each they will have different uuid's and therefore DATA added in one would not transport to the other despite having the same new table

Re: About using the same data file in two different structures...

​> What I'm seeing is the table names don't seem to matter as long as the > Tables and Fields have exactly the same numbers. ​ Yeah, that made sense. Back in the olden days, you could open any 4D data file by creating a 255 table 255 field structure with all text fields. Hence the WEDD file...and

Re: About using the same data file in two different structures...

David, On Sat, Dec 3, 2016 at 4:03 PM, David Adams wrote: > * Now close one method and leave the other open. > > * Go to the structure editor and rename the field something else - say IDX. > > * Now look at the code in both methods. The one that was closed has the new > ​ ​

Re: About using the same data file in two different structures...

> This sort of goes to the heart of what I'm wondering about - if the table > names have any hard relationship with the structure? I'm assuming they > don't, that they are like the method names and 4D tokenizes them internally > and puts on a friendly name when humans are involved. There are

Re: About using the same data file in two different structures...

Hi David, This sort of goes to the heart of what I'm wondering about - if the table names have any hard relationship with the structure? I'm assuming they don't, that they are like the method names and 4D tokenizes them internally and puts on a friendly name when humans are involved. If that's