Search results for query: *

Thank You. You have unwittingly helped resolve a taxing problem of why I could not even connect to my legacy Interdev apps, NIS being the cause. I do agree though that having to disable NIS to do any work does suck. I am sorry I cannot provide any insight to this, maybe in the last few weeks...

Not so much solved, as I could easily have put it there initially, but it has helped me to understand that putting it in the back-end in Access, whilst potentially more elegant, was not a goer. Thanks again for your help.

Hi, the function is in the back end. I have now moved it out to the VB.exe and is used to modify returned data prior to display in the Front-end app.

Just a thought, have you checked the open ports through your internal firewall into the DMZ? I am no expert with VI used in this way but do a lot of work with database conns etc. into a DMZ and this is easily the most common cause of problems.

You are quite right that is a solution but it can be quite clunky if there is a large recordset to parse. I think I accept that I am dreaming a dream too far for dear old Access! Thanks for your help. Karl [smile]

Function "GetAge" resides in VBA module. Query "qryChildren" is defined as a normal query object as follows: SELECT h.Relationship, h.Gender, h.Carer_ID, GetAge([Date_of_Birth]) AS Age, c.Contact_ID, c.Forenames FROM tblCarerHousehold AS h, tblContacts AS c WHERE...

no in this case Access 2000 is being used as the back-end database.

I have a Public VBA function called GetAge which is used within a query within Access 2000. This works fine when the query is run from within Access but fails with the following error message when the query is called via ODBC using ADO 2.5 from VB6: [Microsoft][ODBC Microsoft Access Driver]...