I cut and paste images into an image field on a Paradox form and I've been doing this with no problems for years; yesterday I got a message saying 'Unknown internal operating system error' with a reference to the .MB file, when I tried to paste an image in. Paradox hung. After restarting, I verified and rebuilt the table and it imported the image ok but when I tried to do it with a new record the same thing happened.
I'm using Paradox 10.0.0.663 running on a Lenovo laptop with Vista Home Premium and Service Pack 2. The database has 121,900 records in it but not all of them have images.
Does anyone know what might be causing this? Any help would be appreciated, thanks.
Just wanted to add that blob fields including memos are stored in the .MB file. When you define a memo field you specify something like M20 where the 20 is the number of characters stored (duplicated) in the .DB file. So, if you specify M200 the first 200 characters are duplicated in the .DB file.
By the way, for images, i prefer to save ONLY the image name in the database and put all the images in a folder. I prefer this whether I'm using Paradox tables, an Access .MDB database, MS SQL, whatever. Obvioiusly, thre are times using a Graphic field type in Paradox has it's advantages but generally I prefer to keep images out of the database.
I don't think we should over sell the problems with blob fields. Yes, they have occassional problems. You are using a file based database after all. Yes, the people that have problems post on message boards and newsgroups. All that means is that if 1/1000 people have problems, that .01% are way more likely to post to a board.
Yes, Steve is correct with his general suggestion of "it's not a bad idea to avoid blob field types". However, you can use them. I have been doing this for many years and I can tell you that blob fields are as safe as anything in a file based database. I don't think it's a choice between using blob fields such as memo, formatted memo, graphic, and binary or not. It's a matter of what are the best ways to use a file based databse. In general, SQL servers are more robust with regards to fault tolerance so issues like this are more rare (practically non-existant). For me, the bottom line is that if you choose to stay with Paradox tables, go ahead and use blob fields but listen to Steve (and others) and use them sparingly and not at all for graphics.
As I reread this thread, I see that Steve suggested earlier than I did to use a folder for your images and just store the path in your table. That's how I do this. I never store images in Paradox tables primarily because they get converted to an uncompressed BMP and therefore use up more hard drive space than needed.
As for memo and formatted memo fields. Use them but only when you're sure you need more than 255 characters.
I just don't want to take away a good tool from Paradox users. Memos and Formatted memos are great tools. Yes, backup...backup...backup. Perhaps that's all that we really should say. Backup.
I will expand a bit for clarification for all (this isn't really to you Steve, just some general thoughts):
With ANY data system, backup is critical. With SQL servers you get easier access to backup tools and with Paradox tables, you should be backing up nightly and be prepared to revert to a backup if needed. Actually now that I think about it, all systems should backup at least nightly. So, yes, I agree. Backing up is more than important, it's required.
Blob fields are larger per field within a record and linked from one data segment to the next and therefore can be more problematic if a corruption scenario occurs. So, the real solution is to make sure your file server and workstations NEVER crash. I mean NEVER.
As for whether or not to use blob fields, my recommendation is to go ahead and use them. You are correct that Table Repair will often but not always blank a memo field it can't repair. For example, if you have 10,000 records each with 3 memos, and you have a problem in one record, Table Repair will blank that single memo field, not all the memos in that record nor all the memos in that table. Also, you will NEVER loose data in your .DB table from a .MB memo file corruption. Never.
However, if you are getting corruption, frequently both the .DB and .MB files will get corrupted but that doesn't mean the .MB file corruption caused the .DB corruption. In this case, perception is not reality. Although the perception may be that memo fields caused .DB file corruption, in reality both occurred at the same time from a common enemy.
When I spent 5 years in technical support at Borland, I dealt with corruption frequently. My first question was ALWAYS what is the size of the files involved and what are they supposed to be (checked from a backup). If the backup .MB file is say 10MB and the corrupted file is 1.3MB, I would simply tell the developer to revert to the backup because the data physically just isn't there.
Also, tools like ChimneySweep do a deeper job of attempting to repair corrupted memo fields. Here's a link to a page on Sundial Services website that gives some details of what it attempts with memo fields.
For one of our clients a few years ago, we wrote a Delphi application that went through a Formatted Memo field at tha file level and extracted the data one memo field at a time.
Here's another random thought while we're discussing blobs. It is true that many developers move blob fields to other tables with a 1:1 link in order to further separate memo fields from standard data, and I'm not opposed to that, but that was the reason Borland moved blob data to the .MB file so that's not needed and I don't use that technique myself.
[1/20/10 Edited: Also, I have never seen any evidence that the position of a Blob field in a table has any effect on integrity (moving to the bottom, or near the bottom, of your table structure). Although that's what I generally do, I don't do that because of problems with blobs, I do it out of style. When an MB file goes bad, the DB file frequently also goes bad too. I like all my blobs at the bottom right before my Created, CreatedBy, Updated, and UpdatedBy fields. You can do this one if you want, but I don't believe it is neceassary. I never saw this during my 5 years at Borland nor since but if anyone has any solid evidence of this I'd like to see it.]
Anyway, those are my thoughts for now. I hope this help.
>>... because most people do not make regular, meaningful backups,...
Really, wow, that's hard to believe. How could anyone get by without making quality daily backups. That would mean their data really isn't important to them or they are big risk takers, or ignorant. There are two kinds of computer users in this world, those that backup, and those that will backup.
...Okay, I'm sure my sarcasm is clear. Yes, I agree. If people don't create meaningful backups, they shouldn't use memo fields. Also, they shouldn't use Paradox either. Nor, a word processor or anything that creates data to run their business. So yes, I 100% agree. If you don't backup, start now.
Yes, understood. I apologize if we harped too much on the backup thing. We really were just trying to make a point generally (not specifically to you). I think Steve's run into too many people that haven't backed up properly so his "...because most people do not make regular, meaningful backups.." is probably an exageration and really meant just to encourage business to properly back up.
Most, nearly all, of my clients do regular meaningful backups so I do not have the same experience as he does. I think that's another reason why I'm more on the side of "yes, use memo and formatted memo fields". As discussed, I do generally stay away from the graphic blob field type but not for corruption reasons but rather for data bloating reasons and I just plain like having graphics like that in a single folder outside the database.
I'm glad you posted and clarified your situation. Message boards and newsgroups sometimes tend to have a negative slant toward answering questions and both Steve and I try real hard not to get too negative.
The urban legend crack wasn't directed at you. I did not see that you had wrote that in the thread until now. That came about because I was chatting with one of my Paradox developers Steve Caple. So, I do apologize for that. I'll edit that post to remove the implication that it was directed at you as a slam.
As for the technical details, there is a lot of miss-information out there and I just disagree with you. That's all. Great minds can disagree. Stating that memo fields are unreliable and you therefore should never use them is not good advice in my book.
As for the "...so his comment is an exageration...", I don't see what's wrong with that. I'm sure you agree that it's an exageration to say that "most people do not make regular, meaningful, backups...". There is no question that is an exageration and I thought you were saying that to stress a point. Please don't get offended by that. Businesses using data for their business do generally backup in very meaningful ways. At least most of them.
Thanks Mike, but I think I'm ok now. I have successfully verified and rebuilt the table so everything is fine in that respect and I am happy to be storing my images in a separate directory and just pointing to them from within Paradox.
Hang on, I've just re-read your post and it makes a different kind of sense! I had originally read it as saying 'it doesn't do any good to 'blob' a field' which is why I asked what 'to blob' means...on re-reading I see it differently and assume you're using blob as a noun and that the image field is a blob field and therefore doing a rebuild doesn't do anything to an image field? Correct?
Thanks again. When you say that if the blob field goes south I've lost everything can I assume that you're referring to the blob field contents only? That if the blob field fails then I may lose everything - but just related to that field - and not that there is any danger to the data in the rest of my file. This may sound like a silly question but I wouldn't want to think that by using a blob field I am creating a potential risk to my data itegrity generally.
I have other fields which point to the location of the original copy of the image file on my website, so the copy I have been importing into Paradox and putting in the blob field was really only there to make it quick and easy to see the image, so I seem to be covered from that point of view.
Essentially what I'm hearing is that the blob field is unreliable and I may have to just get used to seeing my images on-line and through the image program but not in Paradox. Correct?
Just wanted to add that blob fields including memos are stored in the .MB file. When you define a memo field you specify something like M20 where the 20 is the number of characters stored (duplicated) in the .DB file. So, if you specify M200 the first 200 characters are duplicated in the .DB file.
Thanks Mike - that explains the reference to the .MB file in the original error. From what I've learned it seems that I'mn unlikely to be able to resolve this one and I may have to learn to live with not having my images actually embedded in the database.....I have tried a rebuild and this time it made no difference. I have stayed with Version 10 because I didn't want to upgrade in case that caused other problems but I'm wondering if a later version might fix it. I suspect not - from what I've been hearing these fields almost 'stand alone' so to speak and whatever is causing the problem is probably not going to be addressed by a later version.
I have done a little more (unsuccesfull) experimenting and I thought I would post the result as it might be a useful bit of knowledge for someone in the future.
I created a single-record file with the same file structure as my main database and attempted to import an image into this - voila! It worked. So I thought I could then get around my problem by creating the records separately and then adding them to the main table. But when I used the add function I found the same 'internal operating system error' coming up again.
So... I thought I would post this even though it didn't fix the problem as it is possible that others have encountered, or will encounter, the same unhelpful error message when adding records from one table to another and it might not be obvious what is causing the problem - but of course if you have a blob field that's probably the culprit!
Well, I've certainly learned something over the last few days. I had no idea blob fields were so unstable! - Steve, thanks for all your advice and Mike, I'll do as you do and just keep my images stored separately from now on - (not that I have any choice, really!)
I've been following the development of this thread with interest and in particular the comments on the importance of backing up; I would like to say that I do backup my files daily, to a separate PC on the network and also to an external drive, so I always have three copies. But rather than go back to a previous version I'm inclined to follow Mike's advice and just use a pointer to the images in my image folder instead of embedding them in Paradox. Even though my data is backed up I don't want to have to go through restoring it if this should continue to occur.
I suppose this posting is just pride - I wouldn't want anyone reading this thread to think I was one of the people Mike refers to who doesn't backup and that my data isn't important to me, or that I'm a risk-taker, or ignorant! Definitely not!
I'd just like to say that nobody can ever be sure how many people are doing regular backups and how many aren't (even though most probably are) ... BUT... it never hurts to repeatedly stress the criticial importance of backing up and if something like this thread happens to catch the attention of some, possibly new, user, who hasn't given backup a thought then that's a good thing. As for the reliability of blob fields (I'm not using the memo fields) - all I can say is that the evidence suggests that they are a weak link in Paradox if only because when an error occurs - as it has in my case - a table repair is not able to fix them.
I realize this thread is fairly complete but I wanted to try my new "reply to a specific post" feature I coded yesterday and I wanted to summarize and clarify a bit.
>>...As for the reliability of blob fields (I'm not using the memo fields)...
I just want to be perfectly clear here for others that read this thread. When you say the above are you really saying that you are not going to use Graphic fields (which are a type of Blob field just like Memo and Formatted Memo)? Also, you'll be doing this out of an abundance of caution. Correct? If so, fine. Also, I definately prefer taking images out of tables and putting them in a folder (as discussed).
As for Memo and Formatted Memo, here is my summary...
The blob fields types are Memo, Formatted Memo (like RTF but not), Graphic, and Binary (use for anything). For the protection of your .DB table data, Blobs are stored in a separate .MB file.
A good rule of thumb is if your text can fit within 255 characters, use an Alphanumeric field type instead. Reserve memo length text fields for when they are truly needed.
Some suggest moving your blob fields to the end of the table (no harm, so go ahead if you wish).
Memo and Formatted Memo are safe to use. I have clients going back to 1993 that are still using them with large tables successfully. I spent 5 years at Borland, wrote 6 Paradox books, and have worked fulltime in the field since, they are as safe as Paradox is to use.
Table Repair DOES attempt to fix memo fields but frequently that means blanking the field. ChimneySweep and other tools do a bit of a better job (try more things before giving up).
The ONLY real defense against corruption is properly backing up so you can restore data when needed.
>> just want to be perfectly clear here for others that read this thread. When you say the above are you really saying that you are not going to use Graphic fields (which are a type of Blob field just like Memo and Formatted Memo)? Also, you'll be doing this out of an abundance of caution. Correct?
first, you should NEVER rely on the Verify option.. there are many, many things that it can't detect.. when in doubt, make a backup and rebuild..
second, it doesn't do anything (good, bad, or otherwise) to blob fields.. essentially, it just ignores them.. the only thing it might have done is fix a bad pointer in the FAT..
blob field.. memo field.. you're calling it an image field.. it's not a regular field type, and isn't associated with the repair tool processes.. technically, you use blob fields at your own peril..
many long-term users have fould that keeping the images/files in a folder, and simply having a pdox field that points to the file name, with a native file reader, is much safer.. many more files to keep, of course, but much safer.. if the blob field totally goes south, you've lost everything..
correct.. memo fields can become unstable, and there is no simple recovery process.. it helps overall integrity to make memo fields the last fields in the table structure.. but you don't have to worry about the memo fields making the regular stuff unstable..
your experiment, and the result, isn't limited to blob field problems.. it's generic, and is something all users should be aware of.. the only difference with blob fields is that there's no built-in tool to fix it..
if you add data to a damaged table, you have still have a damaged table.. if you use the structure of a damaged table to make a new table (instead of creating the new one from scratch), you pass the damage to the new table.. if you query out records from a damaged table, you again have a new damaged table..
obviously, in the rare instance that you have actual, serious file damage, attempting to extract the contents will not eliminate the disaster.. there is no substituate for regular backups.. dee-fence dee-fence !!
in daily use, 99% of all "corruption" is either a table/index out-of-sych error (usually related to improper settings for local share, oplocks, caching, etc.) or an occasional "system burp" that resulted in an incorrect block-to-block pointer in the FAT.. a rebuild re-synchs all the pieces correctly.. anything else described above is just a block-and-copy that propogates the error..
the only simple recovery process for blob data is to scan the table, extracting the blob contents to free-standing files.. there is no guarantee of overall success, of course, but since you already have the files, you don't need to worry about that..
I don't think we should over sell the problems with blob fields.
With all due respect, Mike, I strongly disagree.. the single most important thing that people need to know about blob fields is that, unlike regular Paradox fields, there is no repair or recovery tool.. if the blob field becomes damaged, you can't fix it.. and because most people do not make regular, meaningful backups, that is an absolute recipe for disaster..
for those that do use blob fields, the three cardinal rules:
1) make the blob fields as the last fields of your table - they will be more stable
2) keep editing to a minimum - they will be more stable
no, I've been doing this for about 20 years, and have handled support and problems for probably thousands of people by now.. I don't deal in "urban legends".. and I don't over-state reality and anecdotal history..
you made some good points elsewhere in this thread, but to dismiss expert advice in this manner is rude.. I'll be signing off now..
It's been 19 months (how time flies!) since I started this thread and in the time I have added thousands more records (file size is now 134,000 records) but, of course, with no new blob images. Last week I decided it was time to finally strip the blob field out altogether so (after making a couple of backups of course), I restructured the file, taking the graphics out. After I'd done this, the MBFile, which had been just over 2GB in size, was gone...meaning my backups now take 2 minutes instead of a quarter hour. Unexpected but handy side effect!
Have experienced the disappearance of ALL memo field values (multiple memo fields, thousands of records) in at least one table (although the *.Mxx files still exist). I understand that there's neither a "built-in recovery tool" nor a "simple recovery process" to re-attach .Mxx files to a .DB, but where might I find the explanation of a tool or process--regardless of complexity--to explain how to do it myself? Thanks in advance for any help! Aloha, Philip T. (PT@PhilipT.com)
Member subscribes to this thread with a verified email.
Old Account!
If this is your account, sign in to activate web presence data (sign in quarterly to keep active). Alternatively, you can subscribe to our monthly eMag with a valid email address.
Web Presence Hidden.
Once above is taken care of, full Profile content will display including back links, about me, my message, custom Profile html,
social networking links, message board signature, company profile, etc.
..."the data that was there" is in the .Mxx files. What's the structure of those files (how can I link index/record number from .DB to data that's stored in the .Mxxs?).
the mb file has the existing data, if it's still there.. otherwise, you have to scan from a backup to the current, scan named files into the current, or manually reinsert to the current.. sorry, no majic fix with memo files
Steven Green Senior Software Engineer Paradox Support Specialist DOS/WIN
Prestwood IT Solutions 8421 Auburn Blvd, Suite 256, Citrus Heights, CA 95610 Office: 916-726-5675 | Fax: 916-726-5676 | http://www.prestwood.com
Member subscribes to this thread with a verified email.
Old Account!
If this is your account, sign in to activate web presence data (sign in quarterly to keep active). Alternatively, you can subscribe to our monthly eMag with a valid email address.
Web Presence Hidden.
Once above is taken care of, full Profile content will display including back links, about me, my message, custom Profile html,
social networking links, message board signature, company profile, etc.
Member subscribes to this thread with a verified email.
Old Account!
If this is your account, sign in to activate web presence data (sign in quarterly to keep active). Alternatively, you can subscribe to our monthly eMag with a valid email address.
Web Presence Hidden.
Once above is taken care of, full Profile content will display including back links, about me, my message, custom Profile html,
social networking links, message board signature, company profile, etc.
Member subscribes to this thread with a verified email.
Old Account!
If this is your account, sign in to activate web presence data (sign in quarterly to keep active). Alternatively, you can subscribe to our monthly eMag with a valid email address.
Web Presence Hidden.
Once above is taken care of, full Profile content will display including back links, about me, my message, custom Profile html,
social networking links, message board signature, company profile, etc.
Member subscribes to this thread with a verified email.
Old Account!
If this is your account, sign in to activate web presence data (sign in quarterly to keep active). Alternatively, you can subscribe to our monthly eMag with a valid email address.
Web Presence Hidden.
Once above is taken care of, full Profile content will display including back links, about me, my message, custom Profile html,
social networking links, message board signature, company profile, etc.
Thanks! I've used ChimneySweep before (probably have a license for it!), but I'd forgotten about it. Thanks for the heads-up/reminder! I'll check it out. (As I recall, it was very useful in fixing things that the built-in "fixer" couldn't fix. I'll try to dig it up & see what it can do with these memo fields!)
Paradox
Print This
