Delphi current directory database is not updating Ms Access - delphi

I have a problem in terms on connecting my DbLogSystem.mdb to my program.
1) When I try to insert/update a record using the program, it will proceed and perform successfully,
2) When I try to reset/delete all the records using MS Access it will proceed,
But when I Run my program the data/records are still existing.
What is the possible error?
Thanks in advance.
Below is the connection string that might cause the problem:
mydir := GetCurrentDir;
ADOConnection_get_data.ConnectionString:= 'Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Database Password=puzzle33;Data Source='+ mydir +'\DbLogSystem.mdb;Persist Security Info=False';
or is there any method to link my .Exe program to my Database with the same path folder?

I believe you could just use a relative path to always link your .exe program with the database on the same folder
ADOConnection_get_data.ConnectionString:= 'Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Database Password=puzzle33;Data Source=.\DbLogSystem.mdb;Persist Security Info=False'
As Zam says, check that you aren't alternating with two different database at the Release and Debug folders.
Also, are you sure you are commiting your changes ?. You may be using CommitUpdates (so your changes never really arrive to the database), or you may have an active transaction that you never commit (so it's rollbacked when you exit your application).

Related

How do I recover from TransactionFailureException?

Something went wrong with the application in the middle of a transaction (the thread was killed, which resulted in a ThreadDeath etc.), so the transaction failed, but no new transaction could be started after:
org.neo4j.kernel.api.exceptions.TransactionFailureException:
Kernel has encountered some problem, please perform neccesary action (tx recovery/restart)
What are the actions I should undertake to deal with this issue?
Update: I forgot to mention that I have encountered this type of error before and managed to (at least temporarily) fix it by deleting transaction log files. But now, apparently, there aren't any *nioneo* (IIRC) files in the neo4j data directory at all! Did the location or names of log files change? Or am I missing something? There are neostore.transaction.db.x files, which, upon grepping seem to contain chunks of my data. I did start the fresh instance of the application (fortunately that was a test), so I can't check it now, but if I deleted them, would I be able to restart an app from the previous state?
One of the improvements in Neo4j 2.2 was the unification of transaction logs, those are now in neostore.transaction.db.x.
In case the db does not start any more you can try to remove them (but be sure to keep a backup copy) and restart the database. However try a restart with these files in place beforehand. If the presence of transaction logs causes the database not to start up I would consider this being a bug.

AttachFile locks attachment for deleting on Windows XP

I'd been working on a plugin when I discovered this. I can't say for sure if this behavior happened before or not on my machine (it doesn't on our test server, a Linux box), but after attaching a file, I can't delete it until the server restarts. I can't delete through the UI or by manually navigating to the server directory and trying to delete from there.
Has anyone ever encountered this before? Could it be something environmental on my box??
Most probably it's a permission issue in that folder, which allows your JIRA user (a user under which privileges JIRA instance runs) to create files, but not to delete them (or something even more fun) :) Try deleting the temp folder (where your uploaded attachments reside) and recreate it again, adding your JIRA web user to the access list for that folder.
The workaround to delete files, when some other process is holding a lock on the file, without having to terminate that process, is to use Unlocker. But be warned, when Unlocker unlocks a file it does that in a way which does not notify the lock holder that the file has been unlocked by force. That means that the lock holder still thinks it holds the lock on the open file which it doesn't (the file handle is invalid). That means that some applications might crash due to unexpected state of the supposedly open file. Btw, I've been using Unlocker since forever and it rarely caused any crashes, but it's better to be warned.

"Unable to open the database file" (warning: Wide error)

I cannot seem to get anything out of SQLite other than "Unable to open the database file" on IIS. I'm convinced SQLite's error messages are as brusque as Oracle's.
Pre-deployment in Visual Studio 2010/IIS Express I can both read and write to the file.
When I tried to read/write it with the same VS2010 project deployed to IIS7.5, all "create", "read" and "write" commands fail.
The same occurs when I deploy the database file through the project and try to read it.
I've given Full control access to App_Data and the database file to the following users: IIS_IUSRS, IUSRS, DefaultAppPool, and Everyone.
I've looked at:
SQLite problem "unable to open the database file" (The problem automatically went away for the user) and a number of other similar questions, most of which were solved by changing permissions, changing to a writable directory (App_Data should be writable, no?) or changing a relative path to an absolute one (which |DataDirectory| should resolve to).
<connectionStrings>
<add name="sqlite" connectionString="Data Source=|DataDirectory|\datatables.sqlite;Version=3;" />
</connectionStrings>
Have I missed anything?
<Error>
<Message>An error has occurred.</Message>
<ExceptionMessage>Unable to open the database file</ExceptionMessage>
<ExceptionType>System.Data.SQLite.SQLiteException</ExceptionType>
<StackTrace>
at System.Data.SQLite.SQLite3.Open(String strFilename, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool) at System.Data.SQLite.SQLiteConnection.Open() at AjaxSource.Models.Database.query(String sql, Dictionary`2 parameters) in D:\Tools\Dropbox\Projects\myprojects\AjaxSource\AjaxSource\Models\Database.cs:line 48 at AjaxSource.Models.aaDataModel..ctor() in D:\Tools\Dropbox\Projects\myprojects\AjaxSource\AjaxSource\Models\aaDataModel.cs:line 18 at AjaxSource.Controllers.API.TableDataController.Get() in D:\Tools\Dropbox\Projects\myprojects\AjaxSource\AjaxSource\Controllers\API\TableDataController.cs:line 15 at lambda_method(Closure , Object , Object[] ) at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass13.<GetExecutor>b__c(Object instance, Object[] methodParameters) at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments) at System.Threading.Tasks.TaskHelpers.RunSynchronously[TResult](Func`1 func, CancellationToken cancellationToken)
</StackTrace>
</Error>
I had a problem opening Sqlite database in IIS
(0x80004005): unable to open database file unable to open database
file
what helped me to solve the problem is changing the "Identity" of the application pool to "LocalSystem"
Application Pools -> DefaultAppPool (or another pool you are working with) -> Advanced Settings -> Identity -> LocalSystem
Hopefully it will save someone time...
We used to encounter this problem on the machines of our customers most often, and I have made a lot of investigation upon it and finally we've solved it.
First of all, you need to make sure that your application has read/write access to the database file as well as the folder containing the database file. In most situations, the check will fix the issue; but we are not among those fortunate ones.
In our case, where the application makes very highly concurrent access to the database, it's most probably related to the journal mode of the database, which usually is DELETE by default. That is to say, the rollback journal will be deleted once the corresponding transaction is committed or rolled back. On **nix systems, it's no error; but on Windows systems, it's another story, as can be seen below. On Windows systems, the problem could take place in the following scenario:
A journal file (say A) is created by a SQLite thread.
Another thread P tries to open A.
SQLite has finished its transaction and so deletes the journal file A.
But now thread P has handle for A, so SQLite enters the “Delete Pending” state.
SQLite starts another transaction and has to recreate the journal file (with the same name).
Windows reports ERROR_DELETE_PENDING error (see here for more information: http://blogs.msdn.com/b/oldnewthing/archive/2007/11/09/6001644.aspx)
SQLite report SQLITE_CANTOPEN error (that is, "Unable to open the database file").
P finally releases the file handle and A is deleted.
One solution is to use PERSIST or TRUNCATE journal mode instead of DELETE. See here for more details: http://www.sqlite.org/pragma.html#pragma_journal_mode
In this way, the rollback journal (.-journal) is not deleted at all, and thus we can get rid of the problem you said. I hope this helps.
Well I don't know if this will answer your question, but in my case I had a dummy error which is that I gave a wrong relatif URL to the database file when I copied my code from a commandline projet to the mvc one. Hope someone will find this useful.
It wasn't a permissions problem. The problem is that I didn't check that |DataDirectory| actually resolved to the AppData directory like it's supposed to.
On the IIS 7.5 server, |DataDirectory| resolves to C:\inetpub\wwwroot\AjaxSource\App_Data, but the actual AppData is directory is C:\inetpub\wwwroot\AjaxSource\bin\App_Data.
The errors I caught using Fiddler never mention any paths, but imply a permissions problem. I had one of my views display the resolved directory with:
<h1>#AppDomain.CurrentDomain.GetData("DataDirectory")</h1>
(Oddly, this isn't documented).

Scheduling a Rails task to safely backup the database file

I have a Rails application on a Windows Server 2008 machine. The application uses a sqlite database, and I need to backup it once a day. The backup should be done by coping the database file to a mirrored folder, and a mirror-backup service will take it from there.
There is one problem. I would like to avoid copying the database file while the application uses it. If I copy the file in the middle of an action, I'll get a corrupted and\or locked database file in the backup - and restoring such a file is too much trouble, if it's even possible.
Now, is there a make the scheduled task wait until the database is not in use? Or to prevent the rest of the application from using the database while the backup task is running?
As for the scheduling, I've seen several solutions, but I haven't committed to a scheduling solution yet, so it's possible for me to depend on a scheduling-solution feature to solve the backup problem.
I would suggest using the SQLite Command Line Shell:
sqlite3 /path/to/live.db '.backup /backup/path.db'
This will allow you to backup without causing regular DB operations to fail. From the documentation:
The copy operation may be done incrementally, in which case the source
database does not need to be locked for the duration of the copy, only
for the brief periods of time when it is actually being read from.

Can MS Access 2007 support multiuser environment?

There is an application which is running on several machines(say roughly on 2).This application updates an shared mdb placed on network.Both users are trying to update the shared mdb at one time but the problem is only one user is able to update mdb at one time.Another user is not able to open it.Can anyone suggest that access support multiuser environment?
edit:
There is one form TFormRoadAttrib.When it activates following function is called
procedure TFrmRoadAttrib.FormActivate(Sender: TObject);
if dmTimeDomain <> nil then
begin
if not (dmTimeDomain.dbTimeDomain.InTransaction) then
begin
dmTimeDomain.dbTimeDomain.BeginTrans;
end;
end;
where dbTimeDomain=TADOConnection and its value is
'Provider=Microsoft.ACE.OLEDB.12.0;
Mode=Share Deny None;
Extended Properties="";
Locale Identifier=1033;
Jet OLEDB:Registry Path="";
Jet OLEDB:Database Password="";
Jet OLEDB:Engine Type=4;
Jet OLEDB:Database Locking Mode=0;
Jet OLEDB:Global Partial Bulk Ops=2;
Jet OLEDB:Global Bulk Transactions=1;
Jet OLEDB:New Database Password="";
Jet OLEDB:Create System Database=False;
Jet OLEDB:Encrypt Database=False;
Jet OLEDB:Don't Copy Locale on Compact=False;
Jet OLEDB:Compact Without Replica Repair=False;
Jet OLEDB:SFP=False;
Data Source=Q:\BEL_01\BEL_GADM\ACCESS\Restrictions.mdb;
Jet OLEDB:System database=C:\Program Files\Tele Atlas\Common Files\DPT.MDW;
User ID=dbadpt;
Password=dbadpt;
When we click on Ok button following code executes
if dmTimeDomain <> nil then
begin
if (dmTimeDomain.dbTimeDomain.InTransaction) then
dmTimeDomain.dbTimeDomain.CommitTrans;
end;
end;
Kindly suggest.
Access definitely supports a multi-user environment, but your permissions must be set correctly. All users must be able to create files in the directory where the database is located, and all users must have permission to modify files created in that directory by other users. There are many ways to mess that up. This is because Access uses a separate .ldb file as part of its mechanism for managing concurrent, multi-user access.
A good test is to have one user create a text file in the shared directory, and then make sure the other user can open that file, and then save a change to it.
Both should be able to use the app. If one user is editing a form or table, the others are locked out of editing those same objects. But that should have no bearing on the app once it's in "production" state. A few years ago I helped convert a large app to MS SQL Server backend (stil MS Access frontend) and until that point, they had been successfully using the app with 15 users simultaneously. The app just got too big (100 forms, 100 tables, some with a million rows) so they moved for performance reasons. Otherwise they'd still be totally on Access.
Consider using an Access Project (adp extension) instead of a normal access mdb file. An access project works with SQL server desktop engine which you will find as a separate install file on you Office CD. This essentially means you have a slightly watered down version of SQL server running and this server will take care of all your concurrency issues for you. Also, if your DB becomes too big for an Access Project, you can easily port your DB to a fully fledged SQL Server machine. You can do most of the things in an Access Project that you can do with SQL Server, including Stored Procedures etc, and it's pretty easy to setup and connect to.

Resources