|
Since I'm in desperate mode, I wrote a post build event to modify the installer... all it is doing is removing the entry 'ARPSYSTEMCOMPONENT'. I suppose I'll also need to the do the same with the ARPNOREMOVE, and the others...
Surely I'm not the first person this has happened to.
|
|
|
|
|
So this is what I found out. We are using National Instruments Measurement Studio for .Net and the legacy controls. When using the legacy controls a certain merge module gets recognized as a dependency. For whatever reason, now this merge module change the behavior of the installer that is compiled. I've contacted National Instruments and am now working with them.
|
|
|
|
|
I create MemoryMappedFile like this :
mmf = MemoryMappedFile.CreateFromFile(filename, FileMode.OpenOrCreate, name, length, MemoryMappedFileAccess.ReadWrite);
but after use if i try to remove file from disk it is "in use" :
mmf.Dispose();
mmf = null;
File.Delete(filename); // cause exception
how i can remove it without end of application ? All reader/writer are disposed too.
|
|
|
|
|
have you tried using Finalize() instead of Dispose() ? (just wondering if that would make a difference)
your
mmf = ... line is probably better served wrapped in a 'using' block btw
'g'
|
|
|
|
|
mff has no Finalize() member 
and all MemoryMappedViewAccessor's are wrapped into 'using' blocks, but mmf is "global" and will be accessed from different parts of code.
|
|
|
|
|
What's the best way to notify the front end of a business rule or possible FK violation? For example, I have a lookup called PayType, and so far my DeletePayType looks like this:
public static void DeletePayType(int PayTypeId)
{
using (var dc = getDataContext())
{
bool inUse = isPayTypeInUse(PayTypeId);
if (inUse)
{
throw new Exception("Pay Type is in use and cannot be deleted");
}
else
{
var payType = (from ca in dc.PayTypes
where ca.PayTypeId == PayTypeId
select ca).FirstOrDefault();
if (payType != null)
{
dc.PayTypes.DeleteOnSubmit(payType);
try
{
dc.SubmitChanges();
}
catch (Exception e)
{
throw e;
}
}
}
}
}
Throwing an exception doesn't seem right, but I need the client to know that the pay type is in use and can't be deleted.
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
Yup programming by error - try and delete the record and then inform the user when it fails - start looking for some other employment.
Here is one reason I ALWAYS use a stored proc, the delete procedure check the FK table and only deletes the record if there is no constraint.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Yup programming by error - try and delete the record and then inform the user
when it fails - start looking for some other employment.
I guess I don't get what you mean.
Deleting the record is possible if it's not in use. This isn't programming by error, it's making sure that a FK violation won't occur.
Mycroft Holmes wrote: Here is one reason I ALWAYS use a stored proc, the delete procedure check the FK
table and only deletes the record if there is no constraint.
Using a sproc won't solve the issue - just move the code that deletes it.
Ant any rate, the user needs to be notified if they cannot delete the record. This is a perfectly normal business rule.
If it's not broken, fix it until it is
|
|
|
|
|
Ok a little more detail is required. you have 2 options with this scenario.
You can try and delete the record and hit the constraint and then deal with it by informing the user. This imposes an error on the DB.
You can also query the DB to see if the record can be deleted using an if EXIST query on the related table(s).
The first method is programming by error and is generally used by lazy sods who have no craftsmanship.
The second requires 2 or more round trips to the database and IMHO is a waste of effort. I write a delete procedure that does the checking before it deletes (or deletes the FK children BEFORE it tries to delete the master record). The proc returns the number of master records deleted (1) or failed (0) or if it is not deleting the children and one exists then it returns (-1). This moves the decision into the database and requires one 1 round trip and supplies the feedback to the user if there is an active constraint.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You're still missing what I'm aiming for...
I want to find out IF the PayType record can be deleted. If its PK is in use in another table, then I don't want to try to delete it. I DO however want to tell the user it's in use.
If it's not broken, fix it until it is
|
|
|
|
|
So how are going to find out if the PayType records is in use by another table(s)? Query the related tables and see if the ID is in use!
You could write a generic procedure that queries sysobjects to identify the PKs and their related fields and then query the tables and return a boolean if you can delete the record. A matter of fact that sounds like an excellent widget to build, why is there not one of those?
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
All that's fine, and is what I am already doing... querying the tables that use the PK.
My original question still is "What's the best way to notify the front end of a business rule or possible FK violation?"
Raise an exception? Return a string?
How does the UI find out that the backend can't delete the row?
If it's not broken, fix it until it is
|
|
|
|
|
I would create a special exception type, which is only used for potential business rule violations the user needs to be informed of. Then you can catch that exception at the appropriate location (where the user started the invalid action) and inform the user using a message box or email or whatever.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Mycroft Holmes wrote: Here is one reason I ALWAYS use a stored proc, the delete procedure check the FK
Then you must work in an unusual environment.
Normally the applications that are in use (the code external to the database) should present the requests that even allow that situation.
Thus checking the FK first every time is a waste of bandwidth and adds nothing but complexity.
And allowing the exception in such cases is quite appropriate.
Mycroft Holmes wrote: and only deletes the record if there is no constraint.
But presumably it does in fact still throw an error. If the caller is attempting to delete something and it does not in fact get deleted but still exists then the caller must be told that it did not get deleted. It cannot appear as though it did.
|
|
|
|
|
Actually I do manage this in the VM layer but on the rare occasions where I need to delete a master record there is a stored proc and it never relies on the exception, just the way I build it I guess. Seems many are comfortable with the exception being thrown!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
A couple of options spring to mind immediately.
First, you can create a custom exception type (e.g. PayTypeInUseAndCannotBeDeletedException) and throw that, then catch this type in the UI. This has the advantage of not changing the method signature, but if feels like exception as business logic.
Personally I'd return a status on the method. Probably you can get away with a boolean pass/fail as you only have one failure mode.
public static bool DeletePayType(int PayTypeId)
{
using (var dc = getDataContext())
{
bool inUse = isPayTypeInUse(PayTypeId);
if (inUse)
{
return false;
}
else
{
var payType = (from ca in dc.PayTypes
where ca.PayTypeId == PayTypeId
select ca).FirstOrDefault();
if (payType != null)
{
dc.PayTypes.DeleteOnSubmit(payType);
try
{
dc.SubmitChanges();
return true;
}
catch (Exception e)
{
throw e;
}
}
}
}
}
I'd also get rid of the try/catch around the submit. It isn't achieving anything other than removing potentially useful stack trace (See here[^] if you don't know what I mean)), unless this was intended of course.
|
|
|
|
|
In general, it's a bad idea in a database system to test for the existence of a value and then perform an action based on it as a separate operation. This is because you are working in a multi-user environment where you could have a race condition. So, assuming that you don't want to rely on the database throwing an exception and you having to deal with it, it's best to put the test as part of your delete statement. Then, test to see if there were any rows affected or not - this can then be returned up the chain to indicate that the key was in use at this point.
I'm not a big fan of exceptions to control business logic - they should really just indicate that something was wrong, so I'd just pass the result back up the chain.
|
|
|
|
|
Pete O'Hanlon wrote: I'm not a big fan of exceptions to control business logic
You'd love our code base. And the several hundred custom exceptions to handle such exceptional things as a user not having set up a payment method yet. 
|
|
|
|
|
I'd start by creating a DeletePayTypeResult class and having a flag that indicates if the Pay Type was deleted and a string field containing the reason for not being able to delete. And then I would return this type from the method.
class DeletePayTypeResult {
public bool Deleted { get; set; }
public string ReasonNotDeleted { get; set; }
}
public static DeletePayTypeResult DeletePayType(int PayTypeId)
{
}
|
|
|
|
|
Kevin Marois wrote: What's the best way to notify the front end of a business rule or possible FK
violation?
Normally the front end should prevent business flows that allow that in the first place.
So if it does occur then an exception is acceptable.
Kevin Marois wrote: Throwing an exception doesn't seem right
For the most part is it exactly correct. The FK exists to represent a relationship that must always exist. For that failure to occur it means either a programming bug or a work flow problem. Either represents an 'exceptional' situation and thus an exception is in fact entirely appropriate.
In some cases, mostly where the front end might be less stringent then it might be the back ends responsibility to validate for errors. Reporting errors can have variety of solutions but it is something that the layer, not one specific method, should already have an idiom for dealing with. And exceptions are a possible solution although generally it would not be a generic exception but rather a layer specific one.
|
|
|
|
|
The module should be a windows application, made using visual
studio.There are two parts one for client side and the other for
server side.
Client side: client side part should detect the drive which is plugged
in. The details of the drive and the time for which it was plugged in
should be stored in database of server.
Server side: server side part contains a GUI in which all the IP
addresses of all the systems in the network are given in a list and
whenever an IP address is selected the log of all the drives plugged
in is retrieved from the database. ( for IP addresses there must be IP
detection system inbuilt in the module of server side which will store
the info of all systems in database.)
Please help me out. I don't have much time to submit this module.
Thankyou.
|
|
|
|
|
Shibbi wrote: Please help me out
Help you with what exactly? This is just a specification for the work you are supposed to be doing. Just because you have left it until the last minute to get started does not mean that someone else has to do it for you.
|
|
|
|
|
The module should be a windows application, made using visual
studio.There are two parts one for client side and the other for
server side.
Client side: client side part should detect the drive which is plugged
in. The details of the drive and the time for which it was plugged in
should be stored in database of server.
Server side: server side part contains a GUI in which all the IP
addresses of all the systems in the network are given in a list and
whenever an IP address is selected the log of all the drives plugged
in is retrieved from the database. ( for IP addresses there must be IP
detection system inbuilt in the module of server side which will store
the info of all systems in database.)
Please help me out. I don't have much time to submit this module.
Thankyou.
|
|
|
|
|
Hi To all
I am working on an auctioning system that i am developing with C# .NET 4.0. These auctioneers usually have outside auctions which are carried outside (where it would unreasonable to set up a computer network). The bidding's are recorded on paper and then saved onto the database from the papers.
What I want to do is this, I want each auctioneer to have their own handheld mobile computer like the ones offered by cipher labs (http://us.cipherlab.com/catalog.asp?CatID=7&SubcatID=2). The auctioneer will record each bidding on that mobile computer (these recordings should be saved as text file) so when they decide to upload the the bidding these files will be read by a separate module (developed by me) that will then read the file and save to the data to a database.
So can you assist me with devices and libraries that are compatible with such functions and that will help me achieve this feature that i would like to incorporate into my system
|
|
|
|
|
I think you might be starting with the wrong technology. Those hand held computers are primarily designed for reading bar codes and RF information.
What kind of auction do you envision? Something where the auctioneer posts and item and people bid out loud for it? Silent auction? Internet auction?
Obviously, the vocal bids could be pretty fast paced and difficult to record with something like this. You would be far better off with a tablet solution using Windows, Android or iOS.
I am not sure how much room you have to work with the solution you have above. I would definitely start off with an easier platform. I am sure that a small tablet is every bit as affordable and more technically open to work with.
Barring that, it does not look to me like this mobile computer works on the .NET platform, but rather plain C or BASIC.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
