![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 27 total |
![]() |
Tue, Jan 10 2006 3:41 PM | Permanent Link |
Gordon Turner | I'm using D7 and (for this product at this time) version 3.24 of DBISam.
I have a customer running McAfee Enterprise version 8 who is getting 11010 messages when the program starts. (I open several queries right after opening all of my database tables.) I've seen previous posts about the .DAT file being deleted by anti-virus programs. The curious thing is that I set the PrivateDir value of the session to the same folder as the data files. When the program starts, it creates the data files, but then fails with the 11010 message right after that because the temp .DAT file created in the data folder gets deleted. So what's different about the temp .DAT files than the table .DAT files that an anti-virus program would ignore one and delete the other? Are there any other solutions short of upgrading the product to use version 4 of DBISAM? (Please don't suggest changing AV programs. I'm not in a position to tell my customers what AV they should be using. My product needs to run in spite of the AV programs.) |
Tue, Jan 10 2006 7:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Gordon,
<< So what's different about the temp .DAT files than the table .DAT files that an anti-virus program would ignore one and delete the other? >> You'll have to ask the AV vendor what their logic is regarding this. It varies from product to product. << Are there any other solutions short of upgrading the product to use version 4 of DBISAM? >> If you have the source code to DBISAM, I can send you the changes necessary to make the extensions .TMP for temporary query result tables. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jan 11 2006 9:02 PM | Permanent Link |
Tim,
When you create the temp table files are you using the Windows API to set the property "delete on close"? If so, maybe the antivirus is opening and closing the file before your code does, and on closing, Windows does what it has been told to do. --Bill Sparrow-- | |
Thu, Jan 12 2006 11:26 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Bill,
<< When you create the temp table files are you using the Windows API to set the property "delete on close"? >> Yes, but only during the Open for the temporary table, not for the creation. The temporary table is created, closed, and then opened. << If so, maybe the antivirus is opening and closing the file before your code does, and on closing, Windows does what it has been told to do. >> There should be no way for the AV software to interject API calls into the application. It can hook the low-level file system as a driver, of course, but I don't think it can (or at least should) modify what the application is requesting in terms of the Win32 API parameters, etc. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jan 13 2006 7:53 AM | Permanent Link |
Gordon Turner | Tim,
> If you have the source code to DBISAM, I can send you the changes necessary > to make the extensions .TMP for temporary query result tables. Thanks for the offer, but I bit the bullet and upgraded the app to version 4, just for this one customer. I had planned to do this in the long run anyway, but hadn't had time to deal with automatic conversion of the existing data file. |
Fri, Jan 13 2006 4:08 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Gordon,
<< Thanks for the offer, but I bit the bullet and upgraded the app to version 4, just for this one customer. I had planned to do this in the long run anyway, but hadn't had time to deal with automatic conversion of the existing data file. >> That's good to hear. I'm sure that you won't be sorry that you made that decision. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jan 25 2006 7:45 PM | Permanent Link |
To return to this issue, I was not implying that the AV software could
interject API calls into the application, merely that in the multitasking environment, it can do things to the file in between your various API calls. I think it is safe to assume that the AV software is "watching" for files being created and is receiving notifications. So, if it gets a notification immediately after you create the file, or after you close it, then it might open the file before you get a chance to open it yourself. Since you are using special attributes to open the temporary table's file that you don't use to open a normal table's file, the open could fail due to those options being incompatible where the file is already open. So, where people are asking the question "why should the AV software behave differently for a temporary table versus a normal table", maybe the question should be rephrased as "why is DBISAM's reaction to the AV software different for temporary tables compared to normal tables"? And the answer could be the attributes or mode used to open the file. --Bill Sparrow-- In article <BF0BBE9D-32DD-4EC1-AB94-05FF0D484EAF@news.elevatesoft.com>, timyoung@elevatesoft.com (Tim Young [Elevate Software]) wrote: > *Subject:* Re: Error 11010 > *From:* "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> > *Date:* Thu, 12 Jan 2006 11:26:40 -0500 > > Bill, > > << When you create the temp table files are you using the Windows API to set > the property "delete on close"? >> > > Yes, but only during the Open for the temporary table, not for the creation. > The temporary table is created, closed, and then opened. > > << If so, maybe the antivirus is opening and closing the file before your > code does, and on closing, Windows does what it has been told to do. >> > > There should be no way for the AV software to interject API calls into the > application. It can hook the low-level file system as a driver, of course, > but I don't think it can (or at least should) modify what the application is > requesting in terms of the Win32 API parameters, etc. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > > | |
Thu, Jan 26 2006 8:34 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Bill,
<< To return to this issue, I was not implying that the AV software could interject API calls into the application, merely that in the multitasking environment, it can do things to the file in between your various API calls. >> Temporary tables are opened exclusively. There should be no way that an external process could interfere with the files once they are open. What is happening in this case, however, is that DBISAM is creating the temporary table, closing it, and then re-opening it exclusively. That is what allows the AV software to delete or move the file and causes an error in DBISAM. << I think it is safe to assume that the AV software is "watching" for files being created and is receiving notifications. So, if it gets a notification immediately after you create the file, or after you close it, then it might open the file before you get a chance to open it yourself. >> 100% correct. ![]() -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jan 31 2006 4:18 AM | Permanent Link |
André Kleinschmidt | So the only solution you can provide is a change to version 4?
Is that correct? no work-around no other possibility than telling our customter to choose another AV-guard. sorry but this sounds like marketing strategy, .. we don't fix this problem in your bought version, buy ne next higher one ^_^ I think we maybe should change our db-engine if this really is your only way of providing solutions. |
Tue, Jan 31 2006 6:06 AM | Permanent Link |
"J. B. Ferguson" | > sorry but this sounds like marketing strategy, .. we don't fix this
problem in your bought version, buy ne next higher one ^_^ You've never purchased any software that had new features in a newer version? Microsoft changes SQL Server nearly every year by adding new features. If software developers, you included, never updated their products and continually added new features to current products, we'd still be at "ProductName 1.0.0" > I think we maybe should change our db-engine if this really is your only way of providing solutions. Both of these statements by you are really unfair. Tim does a great job in fixing bugs and other discrepancies in DBIsam and is very attentive to requests from developers. Check these newsgroups for the many discussions on AV product reactions to data files. This itself was a requested feature he added into v4.xx. The discussions and requests came during the version 4.xx lifecycle, not the 3.xx lifecycle. He is now working on v5.0 and probably has a strange aversion to not feeding his family, buying clothes, paying the mortgage, etc. Call it marketing to upgrade features in newer versions...Yes; but please DO NOT infer that Tim is doing this as a ploy to get you to buy an upgrade because he doesn't care about helping you fix your problem! That's just wrong! As a consultant/programmer you should tell your customer all the good news and bad news and the reasons for them. Then let THEM make up THEIR minds as to how they can assist you in resolving the problem. My two cents worth... -- Regards, Jan Ferguson Andri Kleinschmidt wrote: > So the only solution you can provide is a change to version 4? > > Is that correct? no work-around no other possibility than telling our > customter to choose another AV-guard. > > sorry but this sounds like marketing strategy, .. we don't fix this > problem in your bought version, buy ne next higher one ^_^ > > I think we maybe should change our db-engine if this really is your > only way of providing solutions. Andri |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |