Would this be right? Would it get a different sql server process id at that point? I have thought that I might be able to query the sql server process id at the beginning of the transaction, and the point of commit, and if they are different, then rollback instead. (It's a client/server situation, the server encounters the error).ĭoes anyone have a trick or workaround which would enable Uniface proc to spot this very dangerous effect (my business logic integrity is severely compromised by it (for example) updating a delivery note without removing the stock.) If I can spot that this has happened before the commit, I can execute a rollback and either automatically or manually redo the transaction. Normally, Uniface sets $status to -10 if a user tries to modify and store a record which has been locked by another user, but because Microsoft SQL Server does not return a status in this situation, Uniface is unable to do this.Īlthough the userver log file does show a message from sql server about the transaction being killed. These deadlocks are (to my mind) legitimate (in that one transaction is updating SKU A then SKU B, and the other one is trying to do B then A). Read up on Buffering, Remote Data, and Optimizing Access to Remote Data in VFP help.We are encountering a slew of issues with one customer, whose system tends towards large transactions featuring a small range of SKU records, where the transaction is encountering a record deadlock, and being rolled back by sql server. > How are you accessing the remote data? SPT? CA? Remote Views? What ever the method, check the buffermode via CURSORGETPROP("Buffering","MyTable") of the SQL cursor you generate. Why? I thought deadlock only happen to updating. Once the 1st user finished his query, then the others user will be fine. My 2nd users of app will hang if more than ONE user try to access SQL server database at the same time which is retrieving same set of data. Recently, I faced a problem of accessing SQL server data. This will help you realize the actual problem. Read the SQL server documentation on "Locking hints". I am not sure, but this may be the reason. If you have incorporated transaction processing in your program then, you need to keep them short(of short duration). I think the tables are getting locked preventing other users from accessing those tables which are locked.
> My friend, I think the situation you are facing is not a deadlock situation in the actual sense. Could you please point me to that topic specifically? > I am reading the topics you suggested, but still no luck to find any info that can solve my problem. > I am using remote view, buffering mode - 5. In your case you will have to add the WITH (NOLOCK) clause to your view select statement. Use this for CursorAdapters as well as SQL Passthrough. "Select field2, field2, fieldn from mySqlTable WITH (NOLOCK). Keep your Transactions very very short.Ģ. While doing a transaction SQLServer will lock the tables.ġ.
0 kommentar(er)
