|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
Changing structures in v11.2?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. ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?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. ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?Hi Josh,
I'm a little confused, and hope you can clear things up for me. Because not all of our customers upgrade their 4D software at the same time, here is how we have always used 4D for development and deployment... 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? 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? Thanks, Ken On 7/3/08 4:17 PM, Josh Fletcher (4D, Inc.) wrote: > 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. > ********************************************************************** > 4D Server v11 SQL has arrived! > Buy it NOW at http://store.4ddepot.com > > 4th Dimension Internet Users Group (4D iNUG) > FAQ: http://www.4d.com/support/faqnug.html > Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech > Unsub: mailto:4D_Tech-Unsubscribe@... > Post: mailto:4d_tech@... > Options: https://lists.4d.com/mailman/listinfo/4d_tech > ********************************************************************** > 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?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. ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
|
|
|
Re: Changing structures in v11.2?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. ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?Josh,
This might have a very annoying side effect in some rare occasions. Eg. when you receive just a compiled structure (of which you don't have the table info and designer passwords) and a data file and you need to convert this data to your own structure. In previous versions of 4D you could create a new structure with a lot of tables containing enough text fields, open the data file to be converted and use the quick report engine to export the data. Maybe this situation won't pop up very soon, but if the compiled structure is a v11, you'll never be able to open the data with another structure. Perhaps some clever guy might write a tool to force change the UUID of a data file. I think it is a good idea to prevent opening the wrong data file, but there should be a backdoor for someone who probably knows really well what he is doing. IMHO Koen Op 4-jul-08, om 01:07 heeft Josh Fletcher (4D, Inc.) het volgende geschreven: > 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). -------------------- Compass bvba Koen Van Hooreweghe Kloosterstraat 65 9910 Knesselare Belgium bvbaCompass@... ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?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. > 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
RE: Changing structures in v11.2?FWIW,
We always develop our next release separately from the current release. The next release gets new features, and the current release gets bug fixes with the occasional new feature as required for new installations. It's not that bad once you develop good procedures and habits. Using source code management software would be best of course. We choose not to since there are limitations to what you can do with 4D, but hopefully the day is coming that 4D will allow enough hooks to make this a no-compromise possibility. Jeff -----Original Message----- From: Eyring Sent: Thursday, July 10, 2008 2:45 PM To: 4D iNug Tech Subject: Re: Changing structures in v11.2? 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... ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?Hi Ken,
Thanks for your follow-up. I want to take a step back and reiterate something I said before: 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. I welcome your feedback and do not want to imply that *I* have the solution for you. My suggestion, because you seem to feel strongly about this, is to take your comments to the 4D Forums, where this is being discussed and also where 4D Engineering participates. Thanks again. Kind regards, Josh Fletcher Ken Eyring wrote: > 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 -- Josh Fletcher Technical Services Team Member 4D, Inc. ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?Hi Jeff,
For us, the position that 4D has taken with how the data files are tied to the upgraded version of the structure has really got us frustrated. We now need to take time out from our work schedule to evaluate how we will deal with this change. We have customers that are very important to us, that refuse to upgrade due to the cost of the 4D software upgrades (and some are still on 2003 that did not want to upgrade before the upgrade price jumped 50%) -- and we need to continually add new functionality for them. With the position that 4D is taking with tying the upgraded structure to the data file... this complicates our lives because we need to continue to develop with a previous version of the 4D software as well. We have been using 4D software since version 2 (1990) and I'm feeling very resentful that 4D has made a change that impacts us so negatively -- and in addition, I find it difficult to accept that 4D will not allow the developer to override this "feature". Thanks for your thoughts. Best regards, Ken On 7/10/08 2:56 PM, Jeffrey Kain wrote: > FWIW, > > We always develop our next release separately from the current release. > The next release gets new features, and the current release gets bug > fixes with the occasional new feature as required for new installations. > It's not that bad once you develop good procedures and habits. > > Using source code management software would be best of course. We choose > not to since there are limitations to what you can do with 4D, but > hopefully the day is coming that 4D will allow enough hooks to make this > a no-compromise possibility. > > Jeff > > -----Original Message----- > From: Eyring > Sent: Thursday, July 10, 2008 2:45 PM > To: 4D iNug Tech > Subject: Re: Changing structures in v11.2? > > 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... > > > ********************************************************************** > 4D Server v11 SQL has arrived! > Buy it NOW at http://store.4ddepot.com > > 4th Dimension Internet Users Group (4D iNUG) > FAQ: http://www.4d.com/support/faqnug.html > Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech > Unsub: mailto:4D_Tech-Unsubscribe@... > Post: mailto:4d_tech@... > Options: https://lists.4d.com/mailman/listinfo/4d_tech > ********************************************************************** > > 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
RE: Changing structures in v11.2?Ken,
Oh, I agree with you. I think that for some developers, this feature was ill-advised, and it should probably be scrapped altogether. Who exactly was clamoring for tighter coupling of structure files and data files? Since 4D doesn't give us any good tools to manage source code (or even decent hooks that accommodate methods, forms, resources, etc.), they shouldn't make it even harder for those who need the flexibility of moving between different versions. That said, v11 is a huge change, and there are so many new features in v11 that it might not make sense for many developers to offer mere copies of their v2003/4 apps. Jeff -----Original Message----- From: Ken Eyring Sent: Thursday, July 10, 2008 3:21 PM To: 4D iNug Tech Subject: Re: Changing structures in v11.2? Hi Jeff, For us, the position that 4D has taken with how the data files are tied to the upgraded version of the structure has really got us frustrated. We now need to take time out from our work schedule to evaluate how we will deal with this change. We have customers that are very important to us, that refuse to upgrade due to the cost of the 4D software upgrades (and some are still on 2003 that did not want to upgrade before the upgrade price jumped 50%) -- and we need to continually add new functionality for them. With the position that 4D is taking with tying the upgraded structure to the data file... this complicates our lives because we need to continue to develop with a previous version of the 4D software as well. We have been using 4D software since version 2 (1990) and I'm feeling very resentful that 4D has made a change that impacts us so negatively -- and in addition, I find it difficult to accept that 4D will not allow the developer to override this "feature". ********************************************************************** 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?Jeff,
While I'm an in-house developer, I do have the potential to run into this problem. I have a 4 2003 databases and 2 of the structures are identical so this could bite me as well. So far as your comment that with all the new features, it doesn't make sense to offer mere copies of existing databases, this may apply to those who have the time and resources to scrap what they have and start from scratch -- but for a database of any real size, that's a major undertaking. If I were going that route, by bosses would seriously be looking at other solutions instead of just 4D. There's been a hard push to move from 4D to Oracle or mySQL. Most of the reason is name recognition rather than needed speed or features -- but that's something that has to be explained. One of the big advantages of 4D over any other platform has always been the ability to migrate existing databases in a pretty short amount of time. Dennis On Thu, Jul 10, 2008 at 1:37 PM, Jeffrey Kain <jkain@...> wrote: > Ken, > > Oh, I agree with you. I think that for some developers, this feature was > ill-advised, and it should probably be scrapped altogether. Who exactly > was clamoring for tighter coupling of structure files and data files? > Since 4D doesn't give us any good tools to manage source code (or even > decent hooks that accommodate methods, forms, resources, etc.), they > shouldn't make it even harder for those who need the flexibility of > moving between different versions. > > That said, v11 is a huge change, and there are so many new features in > v11 that it might not make sense for many developers to offer mere > copies of their v2003/4 apps. > > Jeff > > -----Original Message----- > From: Ken Eyring > Sent: Thursday, July 10, 2008 3:21 PM > To: 4D iNug Tech > Subject: Re: Changing structures in v11.2? > > Hi Jeff, > > For us, the position that 4D has taken with how the data files are tied > to the upgraded version of the structure has really got us frustrated. > We now need to take time out from our work schedule to evaluate how we > will deal with this change. We have customers that are very important > to us, that refuse to upgrade due to the cost of the 4D software > upgrades (and some are still on 2003 that did not want to upgrade before > > the upgrade price jumped 50%) -- and we need to continually add new > functionality for them. > > With the position that 4D is taking with tying the upgraded structure to > > the data file... this complicates our lives because we need to continue > to develop with a previous version of the 4D software as well. We have > been using 4D software since version 2 (1990) and I'm feeling very > resentful that 4D has made a change that impacts us so negatively -- and > > in addition, I find it difficult to accept that 4D will not allow the > developer to override this "feature". > > > ********************************************************************** > 4D Server v11 SQL has arrived! > Buy it NOW at http://store.4ddepot.com > > 4th Dimension Internet Users Group (4D iNUG) > FAQ: http://www.4d.com/support/faqnug.html > Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech > Unsub: mailto:4D_Tech-Unsubscribe@... > Post: mailto:4d_tech@... > Options: https://lists.4d.com/mailman/listinfo/4d_tech > ********************************************************************** > 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2?Hi Jeff,
Thank you for your thoughts -- your words carry much respect with the 4D community. Perhaps 4D will rethink what they have done. Best regards, Ken > Ken, > > Oh, I agree with you. I think that for some developers, this feature was > ill-advised, and it should probably be scrapped altogether. Who exactly > was clamoring for tighter coupling of structure files and data files? > Since 4D doesn't give us any good tools to manage source code (or even > decent hooks that accommodate methods, forms, resources, etc.), they > shouldn't make it even harder for those who need the flexibility of > moving between different versions. > 4D Server v11 SQL has arrived! Buy it NOW at http://store.4ddepot.com 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech ********************************************************************** |
|
|
Re: Changing structures in v11.2? |