Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 19 of 19 total
Thread Windows XP - Problem with elevatedb #401
Thu, Sep 6 2012 1:50 PMPermanent Link

Fernando Dias

Team Elevate Team Elevate

Antonio,

An additional question, where is the configuration file located, is it in the Program Files folder? It might not be the best practice because of permission issues...

--
Fernando Dias
[Team Elevate]
Thu, Sep 6 2012 2:18 PMPermanent Link

Malcolm Taylor

Antonio Marques wrote:

 As I said, this only happens on Windows
> XP. And usually after saving other files (not using elevateDB or any
> reconnection).  Example: On a preview of a document, we save a .pdf
> copy of it. Then we exit the program, bang, error on elevateDB #401.
> This exact same procedure with same data on windows 7, no problems at
> all.

Antonio

Are you sure that the 'working directory' is not being changed when
saving those other files?  If it is changed, that could explain why the
relative path no longer 'works'.

I do not have any problem on XP, but then I always save the path to my
working directory at startup then use that to build absolute paths to
my data, etc.

Just a thought.
Thu, Sep 6 2012 2:51 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Antonio,

<< When the program closes it makes a backup using an SQL query. That backup
is local, there is a local store witch the program uses to make that backup.
We use that method for about 2 years now, and it works very well, but on
this version we changed elevateDB to a newer version and Unicode version.
As I said, this only happens on Windows XP. And usually after saving other
files (not using elevateDB or any reconnection).
Example: On a preview of a document, we save a .pdf copy of it. Then we
exit the program, bang, error on elevateDB #401. This exact same procedure
with same data on windows 7, no problems at all. >>

It sounds like a "current working directory" issue, but this is how EDB
handles relative paths:

function TEDBLocalDatabaseManager.GetFullPath: TEDBString;
begin
  if IsRelativePath(FDatabase.Path) then
     Result:=IncludeTrailingBackslash(FSessionManager.Settings.ConfigPath)+FDatabase.Path
  else
     Result:=FDatabase.Path;
end;

and IsRelativePath works like this:

function IsRelativePath(const Value: TEDBString): Boolean;
begin
  Result:=True;
  if (Copy(Value,1,1)=PATH_DELIM) or (Copy(Value,1,1)=UNCPATH_DELIM) or
     (StringPos((DRIVE_DELIM+PATH_DELIM),Value) <> 0) then
     Result:=False;
end;

So, for this to fail, the path would have to be considered relative *and*
the configuration path would have to be blank.  Are you changing the
configuration path at all anywhere in your application ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com
Thu, Sep 6 2012 11:40 PMPermanent Link

Barry

Antonio,

Download a free copy of ProcMon from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
which will tell you which files your program is trying to access and which files it fails to open.

Just run ProcMon prior to closing your application. This is the quickest way to locate the problem files.

Barry
(You may want to have ProcMon filter only files your application is accessing.)
Fri, Sep 7 2012 7:06 AMPermanent Link

Antonio Marques

The ConfigPath and LocalConfigPath are relative too. The path on the error 'DADOS\HOR_12-13' is relative to the path of the application, DADOS is what's on the ConfigPath and LocalConfigPath, HOR_12-13 is the db name (the folder of the database).

Fernando Dias - The application is not installed on 'Program Files' folder, it is on a root folder on a local hard drive. I couldn't understand your email :s

Malcolm Taylor - What 'working directory' are you referring too?

Tim Young - Thanks for the code sample, it always help. But I couldn't figure that out yet, my configPath always have a relative path, in my example 'DADOS\'.

Barry - Thanks for the tip, I will use if I need to.
Fri, Sep 7 2012 7:31 AMPermanent Link

Fernando Dias

Team Elevate Team Elevate

Antonio,

<< I couldn't understand your email :s>>
fernandodiasATeasygate.com.pt

--
Fernando Dias
[Team Elevate]

"Antonio Marques" escreveu na mensagem
news:EB1B7302-C2DE-439C-BD03-B6747AAA48A3@news.elevatesoft.com...

The ConfigPath and LocalConfigPath are relative too. The path on the error
'DADOS\HOR_12-13' is relative to the path of the application, DADOS is
what's on the ConfigPath and LocalConfigPath, HOR_12-13 is the db name (the
folder of the database).



Malcolm Taylor - What 'working directory' are you referring too?

Tim Young - Thanks for the code sample, it always help. But I couldn't
figure that out yet, my configPath always have a relative path, in my
example 'DADOS\'.

Barry - Thanks for the tip, I will use if I need to.
Fri, Sep 7 2012 1:38 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Antonio,

<< The ConfigPath and LocalConfigPath are relative too. >>

That's your problem.  Do *not* use a relative path for the configuration.
Any time the current working directory changes, it will break EDB database
access.

From the manual:

http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=delphi&version=7&comp=TEDBEngine&prop=ConfigPath

"All applications accessing the same databases must use the same
configuration file. Failure to do so will result in locking errors. Also, it
is recommended that you do not use relative path names for this property.
Complete UNC path names are the most reliable since they do not rely on
local drive mappings. Finally, the Active property must be False in order to
assign a value to this property."

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com
Fri, Sep 7 2012 3:13 PMPermanent Link

Malcolm Taylor

Antonio Marques wrote:

> Malcolm Taylor - What 'working directory' are you referring too?

See Tim's reply above this post.

If you don't believe that your system's current working directory is
changing and causing the error, you can add some code to display or to
log the full path used at that point in your software.  Then you will
be able to see where it is actually looking when the error is raised.

As Tim advises, use a full driveTongueth or use a UNC path.

Malcolm
Tue, Sep 11 2012 6:22 AMPermanent Link

Antonio Marques

Thank you all for your help! The problem seams to be solved. All I did was to change the configuration path for the absolute path.
Now it's working great on XP and other recent windows...
« Previous PagePage 2 of 2
Jump to Page:  1 2
Image