Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Locking issue when changing the default catalog name
Mon, Mar 2 2009 10:43 AMPermanent Link

Alfred Ghazzi
Hi

I can give a very lengthy description of the problem if required. The short version is, changing the default catalog name from EDBDatabase to
something else causes some locking issue.

Two scripts: one creates the databse and the other creates about 20 tables each with its own set of index and constraint creation statements.

When run inside edbmgr.exe works with no problems whatsoever. When excuted inside my application it failes with EDB_ERROR_LOCK (300)
error.

I tried every possible combination of using (or not using) session, engine, query, script, and database objects. Encrypted, not encripted, signature
changed, not changed, etc... always fails when the script object is executing the creation statement of the first index for the second table.
Something like this:

Create table 1 -> OK
Create index 1 table 1 -> OK
Create index 2 table 1 -> OK

Create table 2 -> OK
Create index 1 table 2 -> Error (Cannot have an exclusive lock on table 2)

I changed the order of the table creation (2 before 1) this time i get the same problem on table 1.

I accessed the database through edbmgr.exe. It opens the databse, I can see the tables, I can access table 1 and  with no problems, write
records to both and no problems. I can see all table 1 indexes, but table 2 has none. I tried to create them in the manager, It opens the dialog,  
then I create an index and press Yes to save and the dialog closes. But as soon as I try to click on the index folder in the treeview under table 2
(to check the existance of the newly created index) the same index dialog reappears with an error dialog on top of it displaying the same error
above.

Long story short, I started to strip my database objects from all the changes and leave them using the defualt values and keep testing with every
change, until I found the source of the problem: I changed the name of the catalog file from the default value which is EDBDatabase to FDDBA.
Every time I do the change I get the error. If I leave it alone (=EDBDatabase) everything works fine!!

So, I thought I pass it to you, most likely it is a bug.

Many Thanks and Kind Rgards

Alfred
Wed, Mar 4 2009 10:35 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Alfred,

<< Long story short, I started to strip my database objects from all the
changes and leave them using the defualt values and keep testing with every
change, until I found the source of the problem: I changed the name of the
catalog file from the default value which is EDBDatabase to FDDBA. Every
time I do the change I get the error. If I leave it alone (=EDBDatabase)
everything works fine!! >>

I doubt very much if the name of the catalog file is causing your issue.
Most likely it is a coincidence.

What version of EDB are you using, and can you send me the scripts that
you're using ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Mar 5 2009 12:53 AMPermanent Link

Alfred Ghazzi
Hi Tim

Thank you very much for your reply...

Currently, I'm in a very tight schedule and the deadline is very close. I kept the Catalog Name unchanged and everything is working fine.

As soon as I finish my delivery, I'll send you the script and a sample application for testing...

Most appriciated for your help...

On another note, regarding filtering during replication. It is very very useful to have it during both LoadUpdates and SaveUpdates. For example if
the Head office databse consists of data belonging to, say 5 sales people, two of them are mobile. Theye are not allowed to read or write each
others data, only the manager is allowed.

Now when Mobile User 1 replicates, we want to get all his data for reporting purposes, except for some Contact records created in his/her
database and are not flagged as either Customer or Supplier (for example). On the other hand when replicating the updates from the head office
to his computer, we do not want to send him records belonging to other users.

By extending the LoadUpdates and SaveUpdates statements with a boolean statement something like this LoadUpdates where Field1 = ? and
Field2 = ? or SaveUpdates Where Field3 = Field1 will be immensely powerfull and useful.

I think it is worth considering...

Kind Regards

Alfred Ghazzi
Thu, Mar 5 2009 3:20 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Alfred,

<<  As soon as I finish my delivery, I'll send you the script and a sample
application for testing... >>

Thanks.

<< By extending the LoadUpdates and SaveUpdates statements with a boolean
statement something like this LoadUpdates where Field1 = ? and Field2 = ? or
SaveUpdates Where Field3 = Field1 will be immensely powerfull and useful.

I think it is worth considering... >>

It's already on the list, and will be addressed in the next month or so.
Things have quieted down lately on the support front, so I'm starting to
make some good progress on 2.03 and will continue to do so with subsequent
releases.

--
Tim Young
Elevate Software
www.elevatesoft.com

Sat, Mar 7 2009 7:18 AMPermanent Link

Alfred Ghazzi
Many Thanks Tim

Alfred
Image