Good Evening Alan This is currently a slightly old install - FreeRADIUS Version 3.0.19. I have however just upgraded to 3.0.25 and I'm still seeing the same. I also upgraded unixODBC/FreeTDS to the latest release too - just in case Just chap from an LNS and data to/from a MS SQL Server.
Running the Query on the MS SQL server I see:
--- (1 row affected)
(1 row affected)
---
So it is correctly updating records - the stored procedure is safe as long as it returns success.
Well, RADIUS does all kind of asynchronous updates to sessions. So there's no guarantee that the session database is the same when you run the query, and when FreeRADIUS runs the query.
This is actually a session that's ended - the SQL table before the query shows the data for this session all correct and ended - In this case it's trying time and time again to update the session to finished - so radacct (for this session at least) won't be changing - I'm wondering if this is a result of the update effectively not affecting the data because it's updating the recored to exacly as it is already?
1) Can you think why FreeRadius is getting -1 as a return.
The TDS / MS-SQL client library is returning that.
Indeed :)
2) Given the stored procedure will return an error IF it can't update the data - is there anyway for us to tell FreeRadius to accept and process OK as long as the Query works.
Except that the SQL library says the query *didn't* work.
Agree - badly worded - I meant the Stored procedure is written so it's virtually impossible for the data we need not to be saved - and I know there can always be edge cases... As long as we get (142) sql1: SQL query returned: success It's processed the update OK - I'm happy to share the Stored procedure if it helps - I'd just prefer it not to be totally in the public. I know in some cases this may not be acceptable - but in this particular use case at the end of a session - worse case the process that cllses zombie sessions will close the session in the background a bit later on. Richard