@Paddles said:
...which is why the guy who reinserts the printer power cable gets more thanks than...
That the "guy" is a hero in offices the world over! Without him many a deadline could easily be missed!
:(
@Paddles said:
...which is why the guy who reinserts the printer power cable gets more thanks than...
That the "guy" is a hero in offices the world over! Without him many a deadline could easily be missed!
:(
It looks like it was designed to return the last instance of wtfclass that had it's member method wtfclass called.
Here I made it self documenting...
-.-
public class Wtf { public static Wtf lastTackWtf = null; public void trackWtf() { lastTackWtf = this; } }
Please don't undo your work if it is actually ready!
Isn't there someone you can talk to about time lost by holding the changes back?
I think your company had this coming. After all they repossess cars.
If it hadn't been your bug it would have been someone else.
Karma works that way.
Next time remember to do this:
Option 1. Best option
Option 2. Do nothing and suffer
Here's what my group does... We have a release script we use for building our releases. Our release script will TAG the release. We always use the format of vX.XX (it's manually maintained). Then the build scripts checkouts the TAG. That way each CVS directory has Tag file indicating the build number. In our build scripts we read in the build number. LINUX method: export releasetag=`cat CVS/Tag` WINDOWS method: SET CVSFOLDER="%~dp0CVS\Tag" set releasetag= IF EXIST %CVSFOLDER% ( FOR /F "usebackq eol=; tokens=* delims=" %%i in (%CVSFOLDER%) do set releasetag=%%i ) Then in our ANT XML file we have: <condition property="env.releasetag" else="HEAD"> <isset property="env.releasetag" /> </condition> <tstamp> <format property="env.buildDate" pattern="yyyy-MM-dd hh:mm aa" unit="hour"/> </tstamp> <delete file="out/version.info"/> <copy file="templates/version.info" todir="out/version.info" filtering="on"> <filterset> <filter token="releaseTag" value="${env.releasetag}"/> <filter token="buildDate" value="${env.buildDate}"/> </filterset> </copy>
@Jaime said:
Riiiight... because having a fairly high-privileged account password in a config file is way less risk than allowing a very controlled amount of LDAP traffic through a firewall.
Your first solution is bad because it takes the web server out of the DMZ, defeating the entire point.
What I'm suggesting makes sense; let explain with Apache and Tomcat:
Apache server in DMZ
Tomcat server in same AD domain as DB
Then you simply configure Apachae server to pass data between outside world and specific apps on the Tomcat server.
What's wrog with this?
Ummm... i've never configured IIS servers but wouldn't the proper solution be to have a pass thru client facing webserver in the DMZ pointing to a webserver in the same AD domain as the DB?
Or you can enable sql authentication and put the password in the web.config because that just make more sense... :S
NM, I'm still learning TSQL; In oracle this would much easier.
:S
If you are using SQL 2005 or later this would do it:
ALTER TRIGGER [SEAT].[TR_TRANSACTION_UPDATE_DATETIME] ON [SEAT].[TRANSACTION] AFTER UPDATE AS BEGIN UPDATE [SEAT].[TRANSACTION] SET UPDATE_DATETIME = GETDATE() WHERE id IN(SELECT id FROM inserted) END
This would not; my bad
ALTER TRIGGER [SEAT].[TR_TRANSACTION_UPDATE_DATETIME] ON [SEAT].[TRANSACTION] AFTER UPDATE AS BEGIN UPDATE inserted SET UPDATE_DATETIME = GETDATE() END