Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 19 of 19 total |
Header information corrupt |
Sun, Oct 31 2010 5:57 PM | Permanent Link |
ClockOn | Oh ok, thanks Rob good to know for future reference too...
|
Sun, Oct 31 2010 5:58 PM | Permanent Link |
ClockOn | ooops, sorry meant Roy...
|
Mon, Nov 1 2010 1:08 AM | Permanent Link |
Gregory Sebastian | "Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message news:F87C75DA-817F-4141-9F1D-D306749B7DFB@news.elevatesoft.com... > ClockOn > > > Just that it could be down to network cards or cabling or even PC > configuration. > > Roy Lambert > Before choosing DBISam, I developed a small test app to evaluate DBISam and 2 other DB Engine products. Among other things, I wanted to find out what it would take to crash or corrupt the tables. The App would programmatically insert a couple hundred thousand records with random data, I would time it for performance. Other times, during the updates I would pull the network cable (tried to simulate loss of network connectivity), shut down workstation/ server, cut power to workstation/ server etc. Anything that would corrupt the darn thing. I found that pulling the workstations network cable or cutting power to the workstation often corrupted the table under local sessions but never under remote connections. With remote sessions, when I pulled the cable, the DBISam server would gracefully drop the connection to that workstation while all other network users remained unaffected by this and could continue as usual. Local sessions mostly affected everyone else connected to the DB. The tables never corrupted when there were no write operations involved. Although this was done on DBISam V3 and Windows ME/ Windows 2000, maybe its still quite relevant. I think the problem is more likely to be closer to the server side. Probably something abnormally terminating or interfering with the db server operation during an update but before a commit/ flush buffer. Quite curious to know what it is Clockon, if you do find the problem pls post back. -- Regards Gregory Sebastian |
Mon, Nov 1 2010 4:23 AM | Permanent Link |
ClockOn | Thanks Gregory. I have more details now. I've had the error come up again and completed a verify and found it's returning an blob offset error.
Now the cause may be our DBISAM service because we are not using the stock version we have built a custom version. Which could be where the offset is coming from but not sure yet. I haven't eliminated the possibility of the computer jus yet because this does sound like it is the usual cause of the corruption. But ill see what I can find in our service... |
Mon, Nov 1 2010 8:07 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << Thanks Gregory. I have more details now. I've had the error come up again
and completed a verify and found it's returning an blob offset error. >> What version of DBISAM are you using ? Also, are you using optimistic or pessimistic record locking ? -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Nov 2 2010 3:45 AM | Permanent Link |
ClockOn | optimistic and 4.22 Build 6 im pretty sure...
|
Tue, Nov 2 2010 5:56 PM | Permanent Link |
ClockOn | Version 4.26 build 3
|
Thu, Nov 4 2010 5:58 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << optimistic and 4.22 Build 6 im pretty sure... >>
The optimistic record locking is the issue if you're seeing BLOB errors. The 4.28 and higher releases have a new BLOB design that fixes this problem, but per the release notes, you cannot mix and match the versions: "There is a new design for the BLOB reading/writing that is not compatible with 4.27 or earlier. Therefore, it is extremely important that you do not mix DBISAM 4.28 applications with DBISAM 4.27 or earlier applications. Mixing the two versions can cause improper truncation of BLOB data, and that includes using a 4.27 application on any data that has been updated by DBISAM 4.28, even if it is not concurrently. The issue is that 4.27 and earlier versions recylcle BLOB blocks on a per-block basis, whereas 4.28 and higher versions recycle BLOB blocks on a per-row basis." This applies to any application that directly access the databases. For example, if your application uses the DBISAM Database Server only, then you would only need to update your DBISAM Database Server to 4.28 or higher in order to fix this issue. The other option is to switch to pessimistic record locking instead, and then you will be able to stay at 4.26. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Nov 4 2010 11:34 PM | Permanent Link |
ClockOn | thanks Tim good to know, we have now upgraded to the latest version (4.3), ill keep you posted...
|
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |