|
I vaguely remember using a 100ms wait time and gave up with an error notification if I looped more than 300 times (30 seconds total) - computers don't get tired or mad about doing the same thing over and over so looping only 3 times because "that's probably enough" is not bringing enough firepower to bear!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Forogar wrote: omputers don't get tired or mad about doing the same thing over and over Bah my laptop will go on strike every time I try and loop database writes it considers too deep, cantankerous bitch that she is.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Forogar wrote: I had the same issue and simply had my copying code loop (with a few milliseconds sleep) until the file was properly closed. Waiting an arbitrary time will be too flaky. Loop it!
I have a method in my static Globals class called FileIsOpen that does the same thing. It loops until the file is closed, or until a time limit is met (throws an exception).
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Hi,
Michael Breeden wrote: problem of hard drive write latency
Liquid Nitrogen.
Michael Breeden wrote: but I am getting an error that the converted file is not accessible
The scenario you are giving does not make a lot of sense to me. It sounds more like something has obtained an exclusive lock on the newly created file. Most likely Windows Defender or whatever third-party security product you are using.
From your service when you create the file... use the LockFile function after calling CreateFile with the FILE_FLAG_NO_BUFFERING flag. Hold the lock for the entire time and finally after you copy the file to the final destination release it.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Liquid Nitrogen.
I've used that. It just works...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You could try using a FileSystemWatcher (.Net) or creating a Folder Watcher.
How reliable this would be I have no idea.
|
|
|
|
|
Not very. The trigger is fired when the file is created, not when it is closed, so he will still have the same problem.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
He can use a FileSystemWatcher for this.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I ran into a similar problem years ago with DOS. I wrote the realtime code for a sucker rod inspection system. Basically the rods move through the detectors at 1 ft/second. I had to take the readings, do some filtering and spot flaws, then send a signal to a paint gun when the flaw passed by the paint gun. Still audir record was required, so I needed to save all of the measurements and filtered results to the hard disk, without missing any days passing by at 1 ft/sec. I made an end of rod detectotion routine and "vomited all the data to the hard disk in between rods. The trick was to tell when the hard disk write was completed to begin searching for the start of the next rod. In DOS it wasn't too hard, but I don't recall how I did it.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
We were sitting around talking about the max possible datetime in SQL server, and the fact that you have to know what it is before you can use it.
I mentioned that .Net types all have a MaxValue property, and one of the DBAs said there was nothing like that in SQL server - "you have to know the value".
I mentioned that we like to avoid using "magic numbers", and asked if SQL Server allowed you to specify common values accessible by all databases on the server, something like this:
DECLARE @@SqlDateTimeMaxValue DATETIME = '9999-12-31 23:59:59.997'
...and was again told that SQL didn't have anything like that.
SQL Server - Welcome to the 80's...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Why would it need one? You can always check validity with TRY_PARSE() or TRY_CONVERT().
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
We need to set a datetime column with the max datetime value. Using magic numbers to do this is just as much a bad idea as it is in .net.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
By using maximum/minimum dates to mean something like "not yet happened" or "not yet known", you are using magic numbers however you look at it - regardless of whether said magic number can be represented by a constant.
Either use a NULL or preferably normalise the database to the point where the appropriate date field either exists or it doesn't.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
In our case, it's "never will happen", and it can't be a null column (so we can't use NULL). The original code was using a date 20 years in the future that was calculated from the current date (so ALL of the valuers in this column are different). FYI, the original code was done in 2012, long before I started working here.
If you use a MaxValue property, it will always be valid, even if that value changes in the host system, (kinda like int and long changing sizes when a new higher-bit OS is introduced). If you're using what the system is telling you what the value is, you're better off. Given that SQL doesn't have a built-in MaxDateTime function, I was hoping for athe ability to set a globally accessible variable. Admittedly, that would result in having to use a "magic number" to set the variable, but at least we could have simply referenced a pre-specified variable instead of having to sprinkle the code with SET @maxDateTime DATETIME='9999-12-31' .
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
It does sound like your predecessors need shooting, rather than Microsoft!
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
You can always write a CLR stored procedure and return SqlDateTime.MaxValue from it.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
We don't do CLR stuff in our database if we can avoid it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
This guy wrote some code to find it: Max Date Value[^]
Quote: This took 7 seconds to run on my machine, fyi.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
#realJSOP wrote: you have to know what it is before you can use it.
If only it was documented somewhere[^]!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's not the point.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Why "something like" this:
DECLARE @@SqlDateTimeMaxValue DATETIME = '9999-12-31 23:59:59.997'
When such a form has never been an issue. Unless what you meant to say was this:
DECLARE @@SqlDateTimeMaxValue DATETIME
SET @@SqlDateTimeMaxValue = '9999-12-31 23:59:59.997'
Which is perfectly acceptable ("Command(s) completed successfully.")
|
|
|
|
|
Assigning a value to a variable when you declare it has been perfectly valid since SQL 2008.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yes, thank-you Richard ...
John's a very busy man these days. What with the ... annoyances and all.
|
|
|
|
|
0) SQL Server has no server-wide variable for the max possible datetime.
1) SQL server does not support adding custom server-wide variables (such as @@ROWCOUNT ), so I can't add one myself.
2) I was trying to avoid doing exactly what you posted. I f*ckin know I can, I was just trying to avoid doing that in EVERY stored proc that needs it.
Are we all clear now?
|
|
|
|
|
Hi All,
Odd to see the newest message is getting for 8 hours old, I wonder if there is an issue?
Glenn
|
|
|
|