Crash: memo data in Visual FoxPro ?

bonbon · Post by **bonbon** » Tue Mar 17, 2009 7:41 pm

I have got my app talking to a Visual Foxpro database, but just one of the records (always the same one) causes the app (and Revolution) to crash. This is running in the development environment, not an executable. It seems to be connected to a memo field.

When I remove the data from the memo field (using a different application), my app displays this record without any trouble. With data in the memo field, it crashes.

The memo field contains nothing more unusual than a couple of names, and two email addresses and phone numbers. I have retyped it to make sure there are no hidden odd characters. It is in the form:
Xxx and Yxx
email:
xxx.xxx@blueyonder.co.uk
yyy.yyy@blueyonder.co.uk

Xxx: 07nnn nnnnnn
Yyy: 07nnn nnnnnn

There are plenty of other records whch contain email addresses, and they display witout any trouble.

I have pared the memo text down to just the first character, and it still crashes the app and Revolution - I get the message "Revolution for Win32 has encountered a problem and needs to close. We are sorry for the inconvenience."

I have tried repairing the memo field (no errors reported), and packing the table. It still crashes.

Please, any suggestions on how to progress ?

(I'll be out for the evening, so I'll check in again tomorrow.)

Many thanks,

Pete

Mark · Post by **Mark** » Tue Mar 17, 2009 9:13 pm

Hi Pete,

Does the record actually contain Xxx and Yyy? I think you will need to tell us the actual text or make up fake names that produce the same crash.

It might be a good idea to post your script here.

Best,

Mark

AndyP · Post by **AndyP** » Wed Mar 18, 2009 3:53 pm

Hi Pete,

Does this still happen if you move the record up or down in your records?

I've encountered something similar to this in a Mysql database where I could find no reson for an error accorring, but moving the record cured the problem.

bonbon · Post by **bonbon** » Wed Mar 18, 2009 5:55 pm

Thanks for showing an interest, and sorry for the delay - I had to go out and earn a living (and I'll have to again in half an hour).

Mark, the memo field in the record actually contained "Paul and Jane" - it's personal addresses etc. But as I said, I can replace the entire contents with just "P" (single letter, no quotes) and it still crashes.

Andy, I'm not sure what you mean by moving the record up or down, but I tried duplicating the record (the new record has a different key), then deleting the old record, then repairing memo fields and packing the table. The app now stays open, but displays nothing in the memo field for this record.

I'd attach a picture of the crash, if I could work out how to ...

The layout has a field defined as a scrollable table object (containing an alphabetical list of surnames) on the left (called "Surnames"), and all fields relating to the current record on the rest of the screen. You can change records by scrolling through the table object (or clicking on it etc). The "on selectionChanged" code for the table is:

Code: Select all

on selectionChanged
   lock screen
   showRecord
   unlock screen
   get flushEvents "keyDown" -- ignore any key repeats

end selectionChanged

and the showRecord code, which goes on a bit (look for the field edNotes - this is where the memo data lives) is:

Code: Select all

on showRecord
   set the itemDelimiter to tab
   put "SELECT * FROM Names WHERE Name_ID = " & item 2 of the selectedText of field "Surnames" & ";" into dbQuery
   put revQueryDatabase(gConID, dbQuery) into curID
   if curID is not a number then
      answer "Error: curID = " & curID
      exit showRecord
   end if
   
-- populate the fields
   put revDatabaseColumnNamed(curID, "Title") into field "edTitle"
   put revDatabaseColumnNamed(curID, "Inits") into field "edInits"
   put revDatabaseColumnNamed(curID, "Surname") into field "edSurname"
   put revDatabaseColumnNamed(curID, "Addr_1") into field "edAddr1"
   put revDatabaseColumnNamed(curID, "Addr_2") into field "edAddr2"
   put revDatabaseColumnNamed(curID, "Addr_3") into field "edAddr3"
   put revDatabaseColumnNamed(curID, "Addr_4") into field "edAddr4"
   put revDatabaseColumnNamed(curID, "Addr_5") into field "edAddr5"

   put revDatabaseColumnNamed(curID, "Home_Area_") into field "edTel1Code"
   put revDatabaseColumnNamed(curID, "Home_Tel") into field "edTel1Number"
   put revDatabaseColumnNamed(curID, "HT_Notes") into field "edTel1Notes"
   put revDatabaseColumnNamed(curID, "Work_Area_") into field "edTel2Code"
   put revDatabaseColumnNamed(curID, "Work_Tel") into field "edTel2Number"
   put revDatabaseColumnNamed(curID, "WT_Notes") into field "edTel2Notes"
   
   put revDatabaseColumnNamed(curID, "Notes") into field "edNotes"

   replace numToChar(13) with empty in field "edNotes" -- get rid of little boxes

   if revDatabaseColumnNamed(curID, "Christmas") = 1 then
      set the hilite of button "chkChristmas" of group "grpCategories" to true
   else
      set the hilite of button "chkChristmas" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Postcards") = 1 then
      set the hilite of button "chkPostcards" of group "grpCategories" to true
   else
      set the hilite of button "chkPostcards" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Pilatescon") = 1 then
      set the hilite of button "chkPilatesContacts" of group "grpCategories" to true
   else
      set the hilite of button "chkPilatesContacts" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Morris") = 1 then
      set the hilite of button "chkMorris" of group "grpCategories" to true
   else
      set the hilite of button "chkMorris" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Fitness") = 1 then
      set the hilite of button "chkFitness" of group "grpCategories" to true
   else
      set the hilite of button "chkFitness" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Music") = 1 then
      set the hilite of button "chkMusic" of group "grpCategories" to true
   else
      set the hilite of button "chkMusic" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Bidsmumsxm") = 1 then
      set the hilite of button "chkBidsMumsXmasList" of group "grpCategories" to true
   else
      set the hilite of button "chkBidsMumsXmasList" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Bashersski") = 1 then
      set the hilite of button "chkBashersSkiGroup" of group "grpCategories" to true
   else
      set the hilite of button "chkBashersSkiGroup" of group "grpCategories" to false
   end if

   if revDatabaseColumnNamed(curID, "Bafricapeo") = 1 then
      set the hilite of button "chkBAfricaPeople" of group "grpCategories" to true
   else
      set the hilite of button "chkBAfricaPeople" of group "grpCategories" to false
   end if

   revCloseCursor curID
      
end showRecord

It's very strange. Best wishes,

Pete

bonbon · Post by **bonbon** » Sat Mar 21, 2009 5:36 pm

Well, I never got to the bottom of it. I tried changing drivers, deleting and recreating records, re-typing all of the data, and still it wouldn't work for this one record.

So I exported the data into an Access database (it's a low-volume, single-user desktop app), and it's working perfectly.

mwieder · Post by **mwieder** » Fri Mar 27, 2009 6:59 pm

I'm coming late to the party here (just noticed the thread). Glad it's working for you in Access at any rate.

Are you storing the memo data as a blob or just as text? Memo fields are a bit weird, and I've had trouble in the past in pure MSAccess as well (no rev involved) with them getting corrupted. If you're still interested in the Visual Foxpro approach, you might store the memo field as a blob and see if it still crashes.

bonbon · Post by **bonbon** » Sat Mar 28, 2009 2:28 pm

It's an interesting question, and I'm afraid the answer is "I don't know". It's an Alpha5v9 native database, which uses Visual Foxpro, but I couldn't say how Alpha5 stores memos. I'll do a bit of digging around and see what I can find.

Thanks for the suggestion.

Pete

sturgis · Post by **sturgis** » Sat Mar 28, 2009 6:21 pm

I have something you might try just for curiosity sake.

Have you tried leaving the memo alone and changing each part of the rest of the record individually to something else?

I ask this because you've changed the memo field to single letters, all kinds of permutations, and only having no memo allows it to work.

My thinking is this. Could there be something odd in the rest of the record that is interacting with the memo field? Your other records work with memo field, this is the only one that doesn't so i'm thinking theres something off in the record itself that is affecting the way the memo field is seen when the record is returned.

If thats the case, should be able to leave the memo alone, change each field of your record one at a time till you find which is the culprit, at which point debugging this becomes easier.

Just a thought.

bonbon wrote:It's an interesting question, and I'm afraid the answer is "I don't know". It's an Alpha5v9 native database, which uses Visual Foxpro, but I couldn't say how Alpha5 stores memos. I'll do a bit of digging around and see what I can find.

Thanks for the suggestion.

Pete

bonbon · Post by **bonbon** » Sun Mar 29, 2009 4:37 pm

Right then ... I've tried changing each of the fields, and it's definitely the memo field which is causing the problem.

It seems to be related to the number of characters in the memo field. Anything up to 118 characters is OK; any more than that, and either the memo field doesn't display anything, or the entire app crashes.

I was wondering whether my ODBC data source is set up correctly ( I don't really know anything about ODBC). My settings are:

Microsoft Visual FoxPro driver
Free table directory (the tables are held in .dbf files, with all of the other associated file types as well)
Collating sequence: Machine

... and there are checkmarks in each of "Null", "Deleted" and "Fetch data in background".

I have a vague recollection that in many databases, the first n characters for each memo in a record are held within the main table files, and any subsequent data is held in separate files. This is beginning to sound as though the connection between "main" table and "overflow" memo files isn't working.

Does this ring any bells ?

sturgis · Post by **sturgis** » Sun Mar 29, 2009 6:21 pm

This is just plain strange, and I'm way out of my league so /shrug Haven't a clue. Its just freaky that its a single record. No clue where to start diagnosing this one.

bonbon · Post by **bonbon** » Sun Mar 29, 2009 6:36 pm

Since my last post, I've been putting more data in other records, and at least it's being consistent ... as soon as you go over the 118 character limit, it doesn't show anything in the memo field for that record, and also sometimes it crashes. So, at least it's not just objecting to a single record, but to anything with too much data in the memo field.

I've been working further on the Access version (again using ODBC), and while it is fine with memo records, I have now discovered that it doesn't support revMoveToPreviousRecord. I would happily use SQLite, but I can't persuade Alpha5 to export the memo field (unless I set it up as a big text field instead, which rather negates the idea of a memo field in the first place).

Thanks for having a look.

sturgis · Post by **sturgis** » Sun Mar 29, 2009 7:20 pm

Don't suppose VFP is tossing out any logged errors that you can look at?

Any chance it could be related to the vfp (ver 8 and 9) memo tip problem? If so, can get around it by turning off memo tips.

Kinda doubt thats it tho.

mwieder · Post by **mwieder** » Sun Mar 29, 2009 7:25 pm

I believe revMoveToPreviousRecord won't work with ODBC databases at all, unless it's been rewritten since the last time I looked at it. When I looked into this, ODBC databases are *always* open in forwardOnly mode, or whatever it's called (lack of caffeine at the moment) for speed.

bonbon · Post by **bonbon** » Sun Mar 29, 2009 7:53 pm

Aha ... in that case ODBC really isn't the thing for me.

Alpha5 will happily export to .csv files, and an online trawl has just uncovered a couple of free tools: SQLite Data Browser 1.3 (which creates SQLite 3.3.5 databases, and can import .csv files), and SQLite Expert Personal (which you can use to change the data type, if necessary, e.g. char to memo). I think this is the way I will go.

Many thanks to everyone for their contributions.

specialsof · Post by **specialsof** » Tue Jul 28, 2009 4:33 pm

I am not sure if this is the issue, but there have been issues with the VFP ODBC driver, and it was probably discontinued (no longer bundled or actively supported) close to 7 or 8 years ago.

I am posting this as I have been a VFP developer since its inception, and perhaps someone might find this thread in the future and hopefully this might be of help. That said, I never used the ODBC as it wasn't needed in my work.

AFter VFP 6, Microsoft started using the OLE DB Provider for Visual FoxPro. See this link for info on how it works with VFP Version 9.

http://msdn.microsoft.com/en-us/library ... S.80).aspx