This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
We are using the community edition of Lightspeed to try it out and it has stopped saving data in tables but is not throwing errors. The tracelogger outputs SQL that looks good. Execution times are generally 0ms which tells me something is up. We are not using the modeling tool but are mapping our classes using attributes. I'm not sure how many classes we have mapped because I don't know if it counts the value objects that we are using as being mapped. We may or may not be over the limit of mapped classes allowed. Could this be why nothing is getting saved in the DB but not errors are being thrown? |
|
|
|
|
We don't count value object types against the edition's entity limit (8 for the express edition), and when you hit that limit we throw an exception rather than just not saving. Also, if the trace logger is emitting SQL and a time then that means that we have sent that SQL and the database has accepted/processed it without an error -- we emit the time only after the command has successfully executed (and we have received confirmation of this from the database). My guess is that there is some other factor which is causing the updates not to appear even though the database claims to have processed them. One guess (a bit unlikely) is that you are using transactions and something has started causing them to be rolled back. Another is that you have inadvertently substituted the connection string for a local, fast test database (without realising it so that you are still looking for the changes to be saved in the "real" database) -- perhaps someone made a temporary change for test purposes, forgot about it and committed it back? If neither of those ideas pans out then it might be worth reverting your code a couple of versions to see if this problem is associated with a particular code change (or an update to the LightSpeed library). |
|
|
|
|
After further examination, I'm seeing that the SQL Server Profiler is recieving a command that would cause this. "SET PARSEONLY ON" is the command. It is coming across right before LightSpeed sends its batch. If LightSpeed is using this in the community edition when the max number of classes that can be mapped is exceeded then that could explain the behavior. Is this what is happening? I can't figure out what the source of the SET PARSEONLY ON command is if it is not LightSpeed. |
|
|
|
|
No, if the number of classes is exceeded then we just throw an exception. I don't believe we ever issue a SET PARSEONLY command. This is very strange. Has this started happening only recently? If you revert to a previous version of your code, does the problem go away? If you have recently updated LightSpeed, does reverting to a previous version make the problem go away? Does SET PARSEONLY occur anywhere within your app code, for example as part of a custom logger? Does this affect all commands, or only certain entity types, or only certain commands (e.g. INSERTs but not SELECTs)? If you create a new test project, is that affected too? |
|
|
|
|
YOU'RE RIGHT! As it turns out I'm a big dufus. We started to experiment with transactions and forgot about that code being there. As it turns out we never completed the transactionscope being used in question. Sorry for the fire-drill. |
|
|
|
