On 03/24/2017 03:09 PM, Clyde Eisenbeis wrote:
> Using http://www.firebirdfaq.org/faq29/ as a reference.
>
> 1) If I understand this website, the CREATE GENERATOR is initiated only once?
Yes. It's a global item like a table, so you just need to create it once
(and commit that change to the DB,.
Am I missing a trick here? I'm reading from a BLOB SUB_TYPE 1 column
using the following:
FbDataReader reader = /* blah */
string text = (string)reader[LONG_TEXT];
It's okay when there is data, but if the column happens to be NULL I get
an error (Unable to cast object of type 'System.DBNull' to
On 27/06/14 17:27, Mark Rotteveel wrote:
On 27-6-2014 18:09, Scott Morgan wrote:
Trying to drop a DB opened with the embedded system, but something seems
to be holding the file open after the connection is closed.
The .net provider has a connection pool, so the physical connection is
still
Trying to drop a DB opened with the embedded system, but something seems
to be holding the file open after the connection is closed.
Test case from a console app:
Console.WriteLine(Attempting to open DB...);
var conn = new FbConnection();
conn.ConnectionString = myConnectionString;
conn.Open();
How do you determine if a backup or restore has succeeded?
e.g. (trying to restore from non-existent file)
var restore = new FbRestore();
... set ConnectionString etc...
restore.BackupFiles.Add(
new FbBackupFile(C:\I\Do\Not\Exist.fbk, null) );
...
restore.Execute();
Runs without
On 25/06/14 14:50, Jiri Cincura wrote:
You need to use Verbose = true. :\
Ah yes, it throws a relevant exception now. Thanks.
Scott
--
Open source business process management suite built on Java and Eclipse
Turn
Components: ADO.NET Provider
Affects Versions: 2.6.5
Environment: Windows XP
Firebird 2.5.1
Reporter: Scott Morgan
Assignee: Jiri Cincura
Assume a table of form:
CREATE TABLE PHRASES ( TEXT BLOB SUB_TYPE 1 );
Then attempt the following, looking
On 09/30/2011 02:21 PM, Scott Morgan wrote:
On 09/30/2011 12:59 PM, Mark Rotteveel wrote:
True, but making sure that you always lock resources in the same order,
is the only sure way to prevent deadlocks.
I think I see the problem:
In Version10/GdsTransaction.cs (copy/paste from
On 09/30/2011 12:59 PM, Mark Rotteveel wrote:
True, but making sure that you always lock resources in the same order,
is the only sure way to prevent deadlocks.
I think I see the problem:
In Version10/GdsTransaction.cs (copy/paste from the Sourceforge SVN
browser, so excuse the formatting)
.
As a temporary fix I changed all locks to refer to the
database.SyncObject, which isn't pretty in terms of scaling, but does
remove the deadlock.
A better solution might involve adding a transaction synch object, not
sure though, as I haven't really had the time to go through the code fully.
Scott
10 matches
Mail list logo
