I am trying to do an update with linq using an explict cast and the changes arent submitting.
Here is the code
Image update = db.Images.Where(i => i.ImageId == imageWithChanges.ImageId).SingleOrDefault();
update = (Image)imageWithChanges;
db.SubmitChanges();
I have an explicit operator in my image class. Can anyone help?
Thanks
The line
update = (Image)imageWithChanges;
is not changing anything. It's merely swapping the thing the variable update points at. If you want to actually change the image, you'd probably have to copy each property from imageWithChanges to update.
Another way you can do this, is to attach imageWithChanges to db.Images and say it was a modified instance:
db.Images.Attach((Image)imageWithChanges, true); // true means "it's modified"
db.SaveChanges();
You say you got it fixed, but don't tell How.
For all others that will read this, I agree with Ruben, you have to Attach it. The error it gives you is valid, you have to either handle concurrency checking (with timestamp or version number) or let last in wins (by setting UpdateCheck to false for all your entity's properties).
Related
I am using below code to get records with specified condition, and then to update only the same records.
$this->db->where('Parameter1', 'TRUE');
$query = $this->db->get('Messages');
$this->db->where('Parameter1', 'TRUE');
$this->db->set('Parameter1', 'FALSE');
$this->db->update('Messages');
This works, but calling two times the same query using where() command seems like wasting of server power. Is it possible to make get() command not reset query or to use the previous record set in the update command?
I doubt this is something you really need to worry about taking up too many resources, and you can't really reuse the where clause in the actual sql query. But if you'd like you can refactor to get slightly cleaner code.
$unread = array('Parameter1'=>TRUE);
$read = array('Parameter1'=> FALSE);
$query = $this->db->get_where('Messages', $unread);
$this->db->update('Messages', $read, $unread);
Note:
In your code your getting every element where Parameter1 is set to true, and then changing every one of those elements to false. This almost certainly is not desirable, but perhaps it is a problem you take care of somewhere else in your real application.
I have a question about a line of code in a vba project I am working on. What does this statement actually mean? I know there is no context here and I could post more code but I'm not sure if someone could just look at this and let me know what this is doing.
txtTerminationDate.Locked = (isLocked Or cboTypeSelect.Column(1) = "Regular")
.locked is a boolean that sets whether you can edit the text box. So it is trying to set it to either true or false based on the logic that follows.
In English, set locked to true if the boolean isLocked is true, or if the value of cboTypeSelect.Column(1) equals "Regular".
if you are asking about TextBox.Locked research can be found here (as answered above) TextBox.Locked
if you are asking about the equal signs, it is useful to know that the first one is an assignment operator and the second is a comparison operator (like an inline if comparison). The equal sign is said to be 'overloaded' in vb.
Adding an object to an IndexedDB objectStore will fail if the key already exists. How can I check for the existence of an object with a given key – preferably synchronously (no reason for another layer of callbacks) and without pulling the object.
I know how to do get requests asynchronously via transactions, but it seems a bit of an ordeal to go through every time I want to add an object.
note Solution only has to work in Chrome (if that helps)
The best way to check existence of a key is objectStore.count(key). Which is async.
In your case, the best option is openCursor of your key. If exists, cursor will come up.
var req = objectStore.openCursor(key);
req.onsuccess = function(e) {
var cursor = e.target.result;
if (cursor) { // key already exist
cursor.update(obj);
} else { // key not exist
objectStore.add(obj)
}
};
So far none of the browsers have the sync API implemented so you're going to have to do it async. An objectStore exposes a get method which you provide it with a key and it'll return you the object (or null) that matches the key.
There's a really good tutorial on MDN that covers using IDB, and getting a record is covered too, but the inlined code is:
db.transaction("customers").objectStore("customers").get("444-44-4444").onsuccess = function(event) {
alert("Name for SSN 444-44-4444 is " + event.target.result.name);
};
If you don't want retrieve the record then you can always used the count method on an index as explained here in the spec. Based on the result of that you can either use add or put to modify the record, it'll save extracting the record if you don't need to.
A bit late for an answer, but possible it helps others. I still stumbled -as i guess- over the same problem, but it's very simple:
If you want to INSERT or UPDATE records you use objectStore.put(object) (help)
If you only want to INSERT records you use objectStore.add(object) (help)
So if you use add(object), and a record key still exists in DB, it will not overwritten and fires error 0 "ConstraintError: Key already exists in the object store".
If you use put(object), it will be overwritten.
The question is why do you want to know this? Maybe you should use another approach?
You can use auto increment, this way you don't need to check if a key exists, you will always get a unique one.
You can also use the put method instead of the add method. With the put the data will be updated if the key exists and if the key doesn't exist the data is added.
Everything depends on the reason why you want to check if something exists.
I have three tables objects, (primary key object_ID) flags (primary key flag_ID) and object_flags (cross-tabel between objects and flags with some extra info).
I have a query returning all flags, and a one or zero if a given object has a certain flag:
SELECT
f.*,
of.*,
of.objectID IS NOT NULL AS object_has_flag,
FROM
flags f
LEFT JOIN object_flags of
ON (f.flag_ID = of.flag_ID) AND (of.object_ID = :objectID);
In the application (which is written in Delphi), all rows are loaded in a component. The user can assign flags by clicking check boxes in a table, modifying the data.
Suppose one line is edited. Depending on the value of object_has_flag, the following things have to be done:
If object_has_flag was true and still is true, an UPDATE should be done on the relevant row in objects_flags.
If object_has_flag was false but is now true, and INSERT should be done
If object_has_flag was true, but is now false, the row should be deleted
It seems that this cannot be done in one query https://stackoverflow.com/questions/7927114/conditional-replace-or-delete-in-one-query.
I'm using MyDAC's TMyQuery as a dataset. I have written separate code that executes the necessary queries to save changes to a row, but how do I couple this to the dataset? What event handler should I use, and how do I tell the TMyQuery that it should refresh instead of post?
EDIT: apparently, it is not completely clear what the problem is. The standard UpdateSQL, DeleteSQL and InsertSQL cannot be used because sometimes after editing a line (not deleting it or inserting a line), an INSERT or DELETE has to be done.
The short answer is, to paraphrase your answer here:
Look up the documentation for "Updating Data with MyDAC Dataset Components" (as of MyDAC 5.80).
Every TCustomDADataSet (such as TMyQuery) descendant has the capability to set update SQL statements using SQLInsert, SQLUpdate and SQLDelete properties.
TMyUpdateSQL is also a promising component for custom update operations.
It seems that the easiest way is to use the BeforePost event, and determine what has to be done using the OldValue and NewValue properties of several fields.
If I have a LINQ to SQL table that has a field called say Alias.
There is then a method stub called OnAliasChanging(string value);
What I want to do is to grab the value, check the database whether the value already exists and then set the value to the already entered value.
So I may be changing my alias from "griegs" to "slappy" and if slappy exists then I want to revert to the already existing value of "griegs".
So I have;
partial void OnaliasChanging(string value)
{
string prevValue = this.alias;
this.Changed = true;
}
When I check the value of prevValue it's always null.
How can I get the current value of a field?
Update
If I implement something like;
partial void OnaliasChanging(string value)
{
if (this.alias != null)
this.alias = "TEST VALUE";
}
it goes into an infinte loop which is unhealthy.
If I include a check to see whether alias already == "TEST VALUE" the infinate loop still remains as the value is always the original value.
Is there a way to do this?
The code snippets you've posted don't lend themselves to any plausible explanation of why you'd end up with an infinite loop. I'm thinking that this.alias might be a property, as opposed to a field as the character casing would imply, but would need to see more. If it is a property, then you are invoking the OnAliasChanging method before the property is ever set; therefore, trying to set it again in the same method will always cause an infinite loop. Normally the way to design this scenario is to either implement a Cancel property in your OnXyzChanging EventArgs derivative, or save the old value in the OnXyzChanging method and subsequently perform the check/rollback in the OnXyzChanged method if you can't use the first (better) option.
Fundamentally, though, what you're trying to do is not very good design in general and goes against the principles of Linq to SQL specifically. A Linq to SQL entity is supposed to be a POCO with no awareness of sibling entities or the underlying database at all. To perform a dupe-check on every property change not only requires access to the DataContext or SqlConnection, but also causes what could technically be called a side-effect (opening up a new database connection and/or silently discarding the property change). This kind of design just screams for mysterious crashes down the road.
In fact, your particular scenario is one of the main reasons why the DataContext class was made extensible in the first place. This type of operation belongs in there. Let's say that the entity here is called User with table Users.
partial class MyDataContext
{
public bool ChangeAlias(Guid userID, string newAlias)
{
User userToChange = Users.FirstOrDefault(u => u.ID == userID);
if ((userToChange == null) || Users.Any(u => u.Alias == newAlias))
{
return false;
}
userToChange.Alias = newAlias;
// Optional - remove if consumer will make additional changes
SubmitChanges();
return true;
}
}
This encapsulates the operation you want to perform, but doesn't prevent consumers from changing the Alias property directly. If you can live with this, I would stop right there - you should still have a UNIQUE constraint in your database itself, so this method can simply be documented and used as a safe way to attempt a name-change without risking a constraint violation later on (although there is always some risk - you can still have a race condition unless you put this all into a transaction or stored procedure).
If you absolutely must limit access to the underlying property, one way to do this is to hide the original property and make a read-only wrapper. In the Linq designer, click on the Alias property, and on the property sheet, change the Access to Internal and the Name to AliasInternal (but don't touch the Source!). Finally, create a partial class for the entity (I would do this in the same file as the MyDataContext partial class) and write a read-only wrapper for the property:
partial class User
{
public string Alias
{
get { return AliasInternal; }
}
}
You'll also have to update the Alias references in our ChangeAlias method to AliasInternal.
Be aware that this may break queries that try to filter/group on the new Alias wrapper (I believe Linq will complain that it can't find a SQL mapping). The property itself will work fine as an accessor, but if you need to perform lookups on the Alias then you will likely need another GetUserByAlias helper method in MyDataContext, one which can perform the "real" query on AliasInternal.
Things start to get a little dicey when you decide you want to mess with the data-access logic of Linq in addition to the domain logic, which is why I recommend above that you just leave the Alias property alone and document its usage appropriately. Linq is designed around optimistic concurrency; typically when you need to enforce a UNIQUE constraint in your application, you wait until the changes are actually saved and then handle the constraint violation if it happens. If you want to do it immediately your task becomes harder, which is the reason for this verbosity and general kludginess.
One more time - I'm recommending against the additional step of creating the read-only wrapper; I've put up some code anyway in case your spec requires it for some reason.
Is it getting hung up because OnaliasChanging is firing during initialization, so your backing field (alias) never gets initialized so it is always null?
Without more context, that's what it sounds like to me.