I know that several of the index formulas I used to have in VFP7 and prior no longer work in VFP9. One that comes to mind is anything with DTOS() and/or SUBSTR(). Yet appended string values seem to work fine. Strange. I just worked around it where I began to use VFP9 to compile code. For the most part I still code and compile in VFP7. The only big deal is VFP7 has a bug where a called Procedure or EXECSCRIPT() block of text is run with Debugger on, when the called Proc/EXECSCRIPT() returns to the calling code I get a hard error that kills VFP (c000006). Other than that VFP7 has been great. BTW, when I do compile in VFP9 I do use SET ENGINEBEHAVIOR 70. It only affects SQL-SELECT statements, not xBase relational links or .cdx index behavior. Maybe someday I will leave the Dark Side and go pure VFP9 and not use ENGINEBEHAVIOR 70 any longer. But for me my VFP7 code has stood the test of time, and I do not like tickling the dragon's tail if it is no necessary <g>.
Gil > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of John J. Mihaljevic > Sent: Thursday, August 21, 2008 11:02 AM > To: [EMAIL PROTECTED] > Subject: RE: Error 2199 > > > Dave and Charlie, > > Would these things be different in V9 than they were in V6? I'll have to > see how the index was created. This is a system that was written > by someone > else a while ago, and they're asking me to bring it into V9. > > Thanks, > > John > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:profoxtech- > > [EMAIL PROTECTED] On Behalf Of Charlie Coleman > > Sent: Thursday, August 21, 2008 11:48 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Error 2199 > > > > > > Also make sure that the strings in the MEMVAR do not evaluate to > > greater > > than 240 characters. > > > > -Charlie > > > > > > At 07:51 AM 8/21/2008 +0100, Dave Crozier wrote: > > >John, > > >I think the problem may well lie in the format of the date field > > between the > > >PC and the index. > > > > > >Look at your "strictdate" and "set date" settings as well as the PC > > >locality. > > > > > >For indexing you should really be using dtoc(<<date>>,1) and never > > >dtoc(<<date>>) or even dtos(<<date>>) as there are no regional effects > > using > > >either. > > > > > >Dave Crozier > > > > > > > > >-----Original Message----- > > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf > > >Of John J. Mihaljevic > > >Sent: 21 August 2008 03:52 > > >To: [email protected] > > >Subject: Error 2199 > > > > > >Hi all, > > > > > >I have an application that's returning an error, and I'm not able to > > figure > > >out why this particular error is being returned. > > > > > >The line of code is: > > > > > > INSERT INTO shipment FROM MEMVAR > > > > > >The error I'm getting is: > > > > > > Error building key for index "c:\abc\shipment.cdx" tag > > "Locitemdat." > > > > > >The SHIPMENT table has an index tag called LOCITEMDAT that is made up > > of > > >LOCATION+ITEM+DTOC(SHIPDATE). LOCATION is c(2) and ITEM is c(20). > > > > > >I also get the error when I select the table first and try to add the > > record > > >another way: > > > > > > SELE SHIPMENT > > > APPEND BLANK > > > GATHER MEMVAR > > > > > >The APPEND BLANK line gives the same error. > > > > > >This is something that works perfectly fine when the system is run in > > VFP6, > > >but we're trying to bring everything into VFP9. When running this in > > VFP9, > > >the error occurs. > > > > > >My first thought was to check SET ENGINEBEHAVIOR, but it doesn't > > appear that > > >anything in there would affect INSERT INTO or APPEND BLANK. > > > > > >Any suggestions/solutions would be greatly appreciated. > > > > > >Thanks very much! > > > > > >John > > > > > > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
