Changing structures in v11.2?
4D, Inc. (7/3/08 1:17PM)
Matt Houghton-Thompson (7/3/08 3:56PM)
Tim Nevels (7/3/08 6:41PM)
Matt Houghton-Thompson (7/4/08 12:11AM)
Ken Eyring (7/10/08 2:44PM)
Jeffrey Kain (7/10/08 4:52PM)
4D, Inc. (7/11/08 10:26AM)
4D, Inc. (7/11/08 1:02PM)
Jeffrey Kain (7/11/08 2:14PM)
Ken Eyring (7/11/08 2:36PM)
Stephen Davies (7/12/08 7:55AM)
4D, Inc. (7/3/08 1:17 PM)
Hi Matt,
This is a feature in 4D v11 SQL. The structure and data file share a
UUID now. This was done to make it more difficult to accidentally
open
the wrong file.
Note that this does not mean the same structure cannot be used with
multiple data files. That still works fine.
When you say "newer version of the structure" I am guessing you really
mean "a different copy of the 2004 structure that I upgraded again" or
something similar?
If the structure is the *same* version 11 structure with new methods,
forms, etc. it should work fine. If you upgraded it again, it's
considered a new/different structure.
Is that clear? I understand that some developers often do this; that
is
reconvert the old structure file. This no longer works with 4D v11
SQL.
4D Engineering is aware of the issue but as of yet we do not (and may
not) have a solution. I.e. any solution would really invalidate the
new
design. But it's still being looked at.
Kind regards,
Josh Fletcher
Matt Houghton-Thompson wrote:
Hello, I am running a converted structure and datafile in v11.2. I
want to change to a newer version of the structure, but I get a
message stating the structure and data files do not correspond. Any
ideas? We do not use WEDD.
-Matt H-T.
--
Josh Fletcher
Technical Services Team Member
4D, Inc.
Matt Houghton-Thompson (7/3/08 3:56 PM)
<7cc88da10807031256gc04e039g2622767d37d77083@...
Hello, I am running a converted structure and datafile in v11.2. I
want to change to a newer version of the structure, but I get a
message stating the structure and data files do not correspond. Any
ideas? We do not use WEDD.
-Matt H-T.
Tim Nevels (7/3/08 6:41 PM)
On Jul 3, 2008, at 6:01 PM, Matt Houghton-Thompson wrote:
Hello, I am running a converted structure and datafile in v11.2. I
want to change to a newer version of the structure, but I get a
message stating the structure and data files do not correspond. Any
ideas? We do not use WEDD.
First, open your old 4D 2004 structure with 4D 2004 and go to
Preferences and check your Database Preferences. Do you see anything
in the WEDD area? If so, you have been using WEDD.
The WEDD values are stored in the structure file -- i believe in the .
4DB file -- and in the data file resource .4DR. v11 does not need
a
.
4DR file any longer -- but if it is there it will use it. Here is
what I would to to totally eliminate the WEDD stuff:
Open the v11 structure and make sure the WEDD value in the structure
is blank. Have 4D create a new, empty data file so you can just get
into Design. Then quit 4D. Make sure there is no .4DR file near
your
data file -- delete it if it's there. Now you should have eliminated
the WEDD data.
Tim
Matt Houghton-Thompson (7/4/08 12:11 AM)
<7cc88da10807032111r32f80d03tfafa147d0dc6b575@...
On Thu, Jul 3, 2008 at 4:17 PM, Josh Fletcher (4D, Inc.)
<jfletcher@... wrote:
When you say "newer version of the structure" I am guessing you really
mean
"a different copy of the 2004 structure that I upgraded again" or
something
similar?
Yes, that is what I did. Since we only have one datafile, I can work
with this.
Ken Eyring (7/10/08 2:44 PM)
Hi Josh,
I don't think you realize the complexity, and the cost in time that it
takes when simultaneously developing (as you suggest) two different
structure files, e.g. in a 2004 structure and a v11 structure. It is
a
nightmare to keep track of all changes -- including debugging, etc...
In our office, when we have decided it was time to start to migrate to
a
new version of 4D... we wrote a few wrapper methods that used the
features of the new version and passed in a flag that was used to
determine what lines of code to run at any given time (based upon what
functionality was needed at the time the method was called).
This technique allows us to comment the changes for the new version
when
we need to compile for the old version -- and comment out the code for
the old version when we need to compile for the new version. This
approach keeps all of the incompatible code (between the two versions)
in one place (or only a couple of places) so it is fairly easy to
comment and uncomment the necessary lines for the respective version
when we need to compile it.
Since no one is screaming about the incompatibility "feature" being a
problem, I have to assume that most developers either don't have a
problem with developing for both 2004 and v11 by modifying their code
in
both versions -- or they have not come across this incompatibility
problem yet -- and when they do... will be very surprised -- I know
that
I was.
We can't follow your suggested path of development. It is a bad
business model for us, that is open to make many mistakes over time.
The only way that we will be able to upgrade to v11 or any subsequent
version is to have most of our customers convert to v11 at the same
time. And at that point in time, we will not develop with 2004
anymore.
I'm surprised that other developers aren't expressing their
disappointment towards the hardships that this limitation
will/is/could
cause.
Best regards,
Ken
On 7/3/08 7:07 PM, Josh Fletcher (4D, Inc.) wrote:
Hi Ken,
Ken Eyring wrote:
Hi Josh,
I'm a little confused, and hope you can clear things up for me.
I'll try my best...
Develop on the older version of 4D (e.g. 2004.x), and deploy in the
older version, e.g. 2004.x, and the newer version, e.g. v11.x (by
opening it with the newer version for compiling). Are you saying
that this approach will no longer work? That each time we send a
newer, compiled version of our compiled database in v11 to a customer
that was previously upgraded to v11, that the new compiled database
is considered different -- and therefore will not work with that
customer's data file?
You're talking about three different things (IMO). Two issues in the
above paragraph:
One is repeatedly converting the same structure. This no longer
works, in the sense that you can't open the same 4D v11 SQL *data
file* with a different *structure file*. The structure file is
*different* because you converted it again (it gets a different UUID).
The second issue is sending a customer new versions of the 4D v11 SQL
structure. This works fine as long as you're starting from the same,
original 4D v11 SQL structure.
It's important to differentiate the two issues for clarity (again IMO).
Please clarify. If what I said above is accurate -- then this new
approach is definitely not a feature. In fact, how would multiple
data files (from different customers) be upgraded so that they are
all compatible with the same structure?
This is the third issue; converting data files "in place". Remember,
the "in place" data files from, say, 2004, don't have a UUID at all.
It will be added at the time of conversion. This also works fine as
long as the same structure is used for all customers (or you
consistently send each customer the "right" structure). Same meaning
same UUID, not the same exact code, forms, etc.
Another way to say it: if you are still developing in 4D 2004 AND you
have converted the structure to 4D v11 SQL at some point, then you
need to make the changes in *both* 2004 and 11, rather than
re-converting.
One other point that's kind of staring you in the face: if you use any
of the new features in 4D v11 SQL (you should, they rock!) you won't
be able to continue making changes in 2004 and re-converting to 11.
I.e. you'd have to make the changes in both places anyway.
This is actually a lot less complex than it seems, as long as you
isolate and understand the different issues. I have a hard time
explaining it for some reason but I hope this helps.
Kind regards,
Josh Fletcher
--
Josh Fletcher
Technical Services Team Member
4D, Inc.
Jeffrey Kain (7/10/08 4:52 PM)
<EB8EBE254C16534D9BC41A91DAECF8780420BD9E@...
It bit me quite a bit in v11 beta testing when I was frequently
converting structures. This seems like a solution in search of a
problem, but maybe this was a highly requested feature.
Jeff
-----Original Message-----
From: Ken Eyring
Sent: Thursday, July 10, 2008 3:56 PM
Hi Jeff,
Thank you for your thoughts -- your words carry much respect with the
4D
community. Perhaps 4D will rethink what they have done.
4D, Inc. (7/11/08 10:26 AM)
Brad,
Bradley D. Perkins wrote:
How will this work on Server? We haven't moved to v11 yet, but I run
both
a production and development/testing server. I routinely make a copy my
production data files and use it as the new development data file?
This is not the issue under discussion.
Using multiple data files is not an issue, as long as the structure
has
the same UUID; i.e. it's the same structure, one copy in production,
one
copy in development. This behavior is unchanged.
The problem is when you convert the structure more than once, thus
generating two different UUIDs.
Kind regards,
Josh Fletcher
--
Josh Fletcher
Technical Services Team Member
4D, Inc.
4D, Inc. (7/11/08 1:02 PM)
Hi Stephen,
Stephen Davies wrote:
What about the situation for OEM developers where we have one
compiled OEM structure being sent to hundreds of 2003 and 2004 (&
possibly earlier) datafiles for both standalone and multi-user (4D
Server)? How will this work with the new 'security' architecture?
It works fine. This is not the issue at hand. One structure can
have
multiple data files and one structure can be used to convert multiple
data files. This still works fine in 4D v11 SQL.
The problem is when you convert the structure more than once, thus
generating two different UUIDs.
(note that I'm not trying to address the feature itself; there has been
a lot of confusion about what it is *exactly* that does not work, so
I'm
trying to keep things as clear as possible)
Kind regards,
Josh Fletcher
--
Josh Fletcher
Technical Services Team Member
4D, Inc.
Jeffrey Kain (7/11/08 2:14 PM)
<EB8EBE254C16534D9BC41A91DAECF8780420C016@...
JÈrÙme,
Thanks for sharing the background on this issue.
Jeff
-----Original Message-----
From: jerome pupier
Sent: Friday, July 11, 2008 12:00 PM
In order to qualify my previous email which was a bit caricatural, I
would like to clarify that what I called a "security hole" has nothing
to do with the common understanding of this expression. There is no
backdoor or security break to access the 4D data through the Web or in
Client/Server while it's running, in 2004 as well as in previous
Versions [...]
Ken Eyring (7/11/08 2:36 PM)
Hi Jerome,
Yes, thank you very much for this information as well as the plans to
implement an option for v11.3.
Best regards,
Ken
On 7/11/08 02:14 PM, Jeffrey Kain wrote:
JÈrÙme,
Thanks for sharing the background on this issue.
Jeff
-----Original Message-----
From: jerome pupier
Sent: Friday, July 11, 2008 12:00 PM
In order to qualify my previous email which was a bit caricatural, I
would like to clarify that what I called a "security hole" has nothing
to do with the common understanding of this expression. There is no
backdoor or security break to access the 4D data through the Web or in
Client/Server while it's running, in 2004 as well as in previous
Versions [...]
Stephen Davies (7/12/08 7:55 AM)
What about the situation for OEM developers where we have one compiled
OEM structure being sent to hundreds of 2003 and 2004 (& possibly
earlier) datafiles for both standalone and multi-user (4D Server)?
How will this work with the new 'security' architecture? Why not have
an option to just turn off this new feature, so if people are truly
worried about such a thing, they can have it, but not if we don't want
it. We have hundreds of users and never this problem. Am still not
sure what problem this feature is the answer to. It seems 4D is
thinking of the situation where one structure, one datafile, and maybe
this is good for that.
Stephen Davies
On 12/07/2008, at 4:25 AM, 4d_tech-request@... wrote:
structure and the data file. Actually this feature is an improvement
of the WEDD link that 4D offered until version 2004. 4D v11 SQL goes
further in the same direction and builds a strong security
architecture able to respond to any future challenge that any mission
critical application might request.
Of course, 4D did listen to developers' requests about migration
issues, and the specific case of maintenance of two versions during a
transitory period. As I said this morning the R&D Department is
currently working on a feature which allows such a manipulation. The
implementation of this fix is in progress.
Reply to this message
Summary created 7/11/08 at 3:36PM by Intellex Corporation
Comments welcome at: feedback@intellexcorp.com