My dev environment: VS2005, SQLServer Mobile, SQLServer 2005 server db, PPC windows app.
Having a problem with pull. First pull works fine. I request an error table from the pull. When I need to repull, I drop the table, but if I try to programmatically delete the error table, I get the message that the table has restricted DDL operations allowed. Apparently Drop is not allowed. Sometimes dropping the main table deletes the error table, sometimes it doesn't. If I try to repull and the error table is there, the pull fails.
I've tried "flushing" my cache by closing my connection and reopening, but that doesn't work.
Any ideas?
I have a similar problem--I have primary key indexes on the table I'm trying to pull which DONT go away when the table is dropped. I can't delete them because they give me the same "restricted DDL operations" error, and the pull fails when they are around.
I posted about it a while back, but never did get a reasonable response. Right now I'm deleting my entire database each time I do a pull, which is a very ham-fisted way of doing it, and it's awful slow. Unfortunately, no one else seems to be able to help...
-Kevin
|||Just to narrow down the problem can you do the following:
Before dropping the main table can you soft-reset the device and drop the main table? I am really interested to know the root cause of the problem. Also please note that, just clicking ok on any device app does not actually close the app but pushes it to background. To termainte the app, you need to go to Start Menu => Settings => System => Memory => Running Programs ==> Stop the process
Thanks,
Laxmi Narsimha Rao ORUGANTI, MSFT, SQL Mobile, Microsoft Corporation
|||Whether I drop it from my program or from QA, I sometimes get the error table deleted, sometimes not. That's after a reset. I'm pretty sure I've got my app closing correctly now, which it wasn't before, but now if I look at memory as you suggest, there is no vestige of my program hanging around. I finally decided I didn't really need the error table anyway and so have excluded it from my pull arguments.
However, a related problem promises to be an even bigger headache. Occasionally, dropping the main table does not manage to delete the appropriate entries in __SysRDASubscriptions, so that when I go to pull that table again, even though the actual table has been dropped, the pull informs me that it can't upupdate __SysRDASubscriptions before of a dup entry (error 25016). And guess what, __SysRDASubscriptions is read-only, so I can't "delete from" either. The only workaround I can think of is to backup the tables I need in my .sdf, trash the original and create a new db - a big hack to say the least.
As to what causes the entry not to be deleted, sometimes the database is corrupt (.Verify returns false), but repairing doesn't take care of __SysRDASubscriptions dirty entry.
Any ideas?
|||Can you please give your email id so that I can contact you offline for faster conversation!
Thanks,
Laxmi Narsimha Rao ORUGANTI, MSFT, SQL Mobile, Microsoft Corporation
|||hi Laxmi, did you get my return email or do I have to post my email address here?|||Hi,
I have the same problem also, I am trying to delete the entry from __sysrdasubscriptions table but its coming back with read only error...any advice on how to accomplish this. What i really wanted to do is drop the table and recreate...since the deleted table is not being deleted from sysrdasubscriptions i need to do it manually...Please help...
michael
|||This happens intermittently in my app. Sometimes the delete table takes care of the sysrdasubscriptions row and sometimes it doesn't. I'm closing down my connection before I do the delete just to make sure there are no pending updates waiting, but I still get the problem. The worst part is that I can't reproduce it consistently. How about in your case - does it always fail to delete the row?|||Hi,
In my case, when i drop the table the entries from the sysrdasubscriptions still remains consistently...it just never deleted but then when i delete the entry it comes back with an error of read only...I am not sure what to do with it...the only solution i can think of is delete the database with a drawback of becoming very slow since it will need to reproduce everything...
best regards,
michael
|||I thought of deleting the db too but that's definitely a last resort.
|||Hello Laxmi - did you get my response to your email.
This seems like a serious problem. Hoping you have some ideas other than deleting the database.
|||Sorry guys I am totally lost in my work. I am really sorry about that.
Please send across the repro details along with the repro database at our BLOG http://blogs.msdn.com/sqlmobile/.
Thanks,
Laxmi Narsimha Rao ORUGANTI, MSFT, SQL Mobile, Microsoft Corporation
|||Hi
I am getting the exact same problem.
Any news on a fix for this?
Regards Andrew
|||Having had ZERO help after promises and promisesfrom Microsoft, we finally took the hard core approach and delete the
entire database, so as to ensure the deletion of the subscriptions
info.
As usual, MS releases beta, well more like alpha, products to the
marketplace and relies on its market domination to keep even the most
disgruntled of customers in their camp. However, we have deployed
this as only a temporary solution. In three months, we will be
rearchitecting with a Java solution, with a prototype already working
more reliably than the MS ***. This was only one of many
disappointments for us from MS, and so now we are turning the corner
and going with a more reliable framework, and just better solutions in
general. Too bad MS feels that don't really have to deliver
anything of quality anymore. No wonder their stock is a dinosaur
stuck in the toilet.
Good luck to you...|||
Hi Braden,
This problem is in locating the other sql mobile dlls while dropping the table.
This problem does not appear if you have all of the following in a single directory:
1) SQL Mobile product DLLs
2) SQL Mobile tools (such as ISQLW30.EXE in case you are using it!)
3) Customer application which uses RDA
4) Any other binary that is using SQL Mobile binaries
Please be patient while we work on the problem.
Thanks,
Laxmi Narsimha Rao ORUGANTI, MSFT, SQL Ev, Microsoft Corporation
No comments:
Post a Comment