Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 5 of 5 total |
Locking issue when changing the default catalog name |
Mon, Mar 2 2009 10:43 AM | Permanent 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent Link |
Alfred Ghazzi | Many Thanks Tim
Alfred |
This web page was last updated on Sunday, May 5, 2024 at 10:18 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |