Raul


>> And do you think there is any reason why these problems only appeared with windows 10 after years of regular operation?
>
>Microsoft is changing (breaking) a lot with Windows 10 - there have been
>about 6 or 7 releases of Windows 10 already and they are adding thinds
>and deprecating features also. Due to this frequent cycle i think there
>is also less testing (i.e. we're the testers).

+ several hundred

Roy

Mirco,

<< So in this case is better to put the PrivateDir in a known path instead of the default? >>

I don't know which version of DBISAM you're using, so I can't answer that.  There have been some recent changes to how DBISAM handles the TDBISAMSession.PrivateDir property, and whether the PrivateDir property is published (it's now just public in the latest releases).

In general, as long as your PrivateDir property is set to a local drive, you should be okay.

<< And do you think there is any reason why these problems only appeared with windows 10 after years of regular operation? >>

Because Windows 10 is a new release with changes to how it behaves as an OS.  I've seen Windows 10 go out to lunch scanning the local hard drive on a touch tablet that I use, and it makes the machine virtually unusable.  Luckily, this only seems to occur after restarts and it eventually settles back down, but it doesn't seem to have any concern for whether the machine is currently being used or not.  If you happened to run your query when this was going on, you could get some pretty skewed query execution times.

If you want to email me your data, I can tell you how fast your queries are on various Windows 10 boxes, from a very fast new i7 desktop, an older i7 desktop, an older i5 laptop, and a fairly slow touch tablet.  It will also allow me to see if there are any issues here with the queries.  If they're slow here, then there's something particular to Windows 10 and not specifically your machine/OS/installed applications combination.

Tim Young
Elevate Software
www.elevatesoft.com

Now I have reinstalled windows 7 in the same machine but the problem still there.
In other installations it also happens that the program crashes after saving some data on DB and the problem seems similar although in this case I have not yet been able to investigate thoroughly to understand the problem.
The version is 4.46b1
Thanks.

Mirco


If you reverted to W7 you may have simply carried the problem along, if you did a full wipe and reinstall its different.

If its not AV then it could be DBISAM, your software, some other piece of software, hardware.

I think DBISAM can be left out because if it were that a lot of angry customers would be beating Tim up unless is a rare edge case (I had one of those many years ago with threads)

If its occurring on multiple machines that suggests that its not hardware (unless they're all connected in a network) and unless they all share some piece of software it suggests your code. That makes it very difficult unless you can produce a test case for it.


Roy Lambert

Yes, my first thought was obviously "possible that only happen to me?" But in this particular software nothing has changed except the database version. Instead the problem that happens to me in another part of the program is different and for this reason I asked if as general information I can assume that if I execute the instruction after the ExecSQL() all the operations on the database are ended? Or maybe the call triggers a process that in turn operates on the DB and therefore the operations can take place even after the ExecSQL()?

Thanks

Mirco

>Yes, my first thought was obviously "possible that only happen to me?" But in this particular software nothing has changed except the database version. Instead the problem that happens to me in another part of the program is different and for this reason I asked if as general information I can assume that if I execute the instruction after the ExecSQL() all the operations on the database are ended? Or maybe the call triggers a process that in turn operates on the DB and therefore the operations can take place even after the ExecSQL()?

As far as your program is concerned the database operation is finished. Unless you run the query in a thread, or have another thread running your program will process the ExecSQL before it moves on to anything else. If you have threads running that's different and you can get interference.

However, although you program may think its done with the data Windows may think differently. There are buffers all over the place (including in ElevateDB these days) and they may or may not have been written to disk. There's also AV which can grab things and hold onto them just long enough for things to time out.

You could download the Sysinternal tools and watch what's going on with ProcessMonitor. You need to be ready to wade through a lot of stuff though

Roy

On 4/15/2019 7:37 AM, Mirco Malagoli wrote:
> Yes, my first thought was obviously "possible that only happen to me?" But in this particular software nothing has changed except the database version. Instead the problem that happens to me in another part of the program is different and for this reason I asked if as general information I can assume that if I execute the instruction after the ExecSQL() all the operations on the database are ended? Or maybe the call triggers a process that in turn operates on the DB and therefore the operations can take place even after the ExecSQL()?

I was trying to read thru this thread and i'm still not exactly sure
what is happening exactly - you mention that application crashes but i'm
not sure of any other detail.

You mentioned that app uses local DB (local engine) and other clients
use DBSRVR and C/S - i assume it's the local session that crashes !?

Maybe if you can describe what exactly is happenign we might be able to
suggest more specific things to try.

As to the other points:

1. In terms of ExecSQL - yes once it completes all related database
operations have ended.

Like Roy mentioned it's possible there can be windows file caching in
play but unless you PC loses power at that point windows will complete
the disk writes so files will be consistent.

You could do additional disk flushing but i use dbisam daily on Win10
and there are no common issues i have seen and i do have AV active.

The only other aspect i can think of is if you're using explicit
transactions in your code you need to commit (or rollback) to make sure
transaction is now active.

In DBSRVR there is really nothing else operating on the database in the
background or otherwise except your application code.

2. Assuming you were using an older version of the DBISAM are you 100%
sure you have addressed all breaking changes ?
For example as of 4.45 or newer you need to make sure everything that
uses database direct is configured properly for LargeFileSupport (i.e.
4.45 or newer or LargeFileSupport enabled).


3. Current version is 4.48 so any chance you can try that - there have
been additional changes and fixes in 4.47 and 4.48 relative to 4.46.

4. Finally if you can describe the issue in more detail we could try to
help and reproduce here if possible code snippets or such etc

Raul

First of all, thanks for the help.
Yes the application that crashes is the one that works with the local session.

The request to run ExecSQL () was only to insert a log to try to identify the point causing the problem. Specifically, this application works directly on the database with a local session while also activating a server (via TDBISAMEngine) for the other applications that use it. It is possible that some of the other applications use an older version of components and I don't remember if largefilesupport is enabled or not, but can this create that kind of problem?

Sorry but lately I am having several problems, it all seems to be starting from the DB version update. In this case the problem of blocking the execution of the query as described above seems to appear only on a specific PC, so I am not very worried (in the meantime I have removed the tables in memory to see if it improves), while I have another problem of blocking the same application after writing to DB through an ExecSQL which unfortunately happens more frequently and which has not changed except for the DB version.
Then I had problems installing version 4.46 and trying to access a 4.40 server with different access errors denied to the table and its temporary copy for no apparent reason, returning to the previous version everything is back to normal.
Another problem that I had, written in another post, is that if I move the "DBISAMServer" from the local PC where the application works to a server2012 the application stops executing a select query and in this case the the only difference is the position of the DBserver (although in this case there is an update of the TXDBGrid grid for display).
The sum of all these problems made me think of a database version problem and now I'm bringing all the software back to a previous version to try to determine where the problem comes from (or problems given the amount of blocks that are happening).
My request was only to find out if others had had some problems with the change of version and to seek some help to arrive at a solution.

Thanks anyway
Mirco

On 4/16/2019 8:33 AM, Mirco Malagoli wrote:
> The request to run ExecSQL () was only to insert a log to try to identify the point causing the problem. Specifically, this application works directly on the database with a local session while also activating a server (via TDBISAMEngine) for the other applications that use it. It is possible that some of the other applications use an older version of components and I don't remember if largefilesupport is enabled or not, but can this create that kind of problem?

No - only apps that directly access the database files need to be
LargefileSupport enabled. In case of C/S access only the server has to
have LargefileSupport enabled (C/S clients do not need to be).

> My request was only to find out if others had had some problems with the change of version and to seek some help to arrive at a solution.

Not running into anything like this myself (on 4.48).

Raul

Mirco,

<< The sum of all these problems made me think of a database version problem and now I'm bringing all the software back to a previous version to try to determine where the problem comes from (or problems given the amount of blocks that are happening). >>

If this functionality that is having trouble works fine in your development setup, then it is highly likely that the problem is *not* with DBISAM, but something external.

Tim Young
Elevate Software
www.elevatesoft.com