Lots of tutorials out there, but I figured I’d slap in here for the sake of it.
On Leopard you need to use dscacheutil, which will clear it up for you;
dscacheutil -flushcach
On Tiger (and some upgraded versions of Tiger to Leopard… weird)
lookupd -flushcache
This will help clear up your situation. Now remember, that just because your Mac has cleared the cache, doesn’t mean your browser has. You will still have to clear it in this way.
Ok, this is another gotcha. If you are running Stored procedures on MSSQL via FreeTDS and the procedure has inserts into fields not explicitly set to allow nulls it will fail - however via query analyser it will work ok.
Problem is Query Analyser by default sets “ANSI_NULL_DFLT_ON ON” so the following code will work
Create table #Included_Usage (id int ,TotalUsage float null, EligibleUsage float null, EligibleLength int null, Airtime int null)
insert into #Included_Usage( NULL,’101′,’2′,2,4 );
However from FreeTDS it will bork. You have two options - attempt to set ANSI_NULL_DFLT_ON before running the proc, or change the proc to explicity allow nulls
Create table #Included_Usage (id int null,TotalUsage float null, EligibleUsage float null, EligibleLength int null, Airtime int null)
cI prefer the second alternative. I always like to err on the side of explicit definition, rather than implicit. Usually saves someone from bashing their head on something.
Found this little gem (or rather tripped over it) recently.
We were calling some MSSQL stored procedures from an OSX Server with PHP5 / FreeTDS (0.6.4) and experiencing bizarre results. The stored procedure would simply halt midway through operations. Running the same query via Query Analyser and it worked flawlessly.
FreeTDS was the first suspect - having tripped over TDS Client configuration previously with MSSQL stored procedures doing inserts with NULLs. Butwe needed more information.
Running a trace via MSSQL Server yielded better results. We could see where the procedure was dying. Root cause - one of the MSSQL DBAs had a nasty habit of adding semi-colons after each declare statement. When calling from ODBC etc this didnt seem to be an issue - but FreeTDS saw the semi-colon - assumed the statement was over - and exited, stage left.
Lesson - semi-colons in MSSQL stored procedures are not necessary and best avoided like the plague if you wish to access the procedure via FreeTDS.
So we figured that there are too many people hanging around the WHS office, bragging about how good they are at stuff so we laid down the challenge. Put up, or shut up.
This is the result of that challenge.
WHS and MGSK have teamed up to provide the results to you all - the general internet populus. We hope that you find the information contained in here rewarding, informational, usefull and etc. If not, please feel free to let the author of the guide or trick, or solution know.
We havent got the site open to registrations as yet, but we will shortly. So stay tuned.
In the mean time, feel free to read around and tell us what you think via email:
helped@wehostsheep.net