Hi!
In Win2000 odbc.ini is replaced by odbc.ini subkey in registry. Instead of direct access to ini files you should use appropriate ODBC API functions (as it made in ODBC_DSN class). Also take a look on ODBC API functions SQLGetPrivateProfileString and SQLWritePrivateProfileString:
"SQLGetPrivateProfileString is provided as a simple way to port drivers and driver setup DLLs from Microsoft® Windows® to Microsoft Windows NT®/Windows 2000. Calls to GetPrivateProfileString that retrieve a profile string from the Odbc.ini file should be replaced with calls to SQLGetPrivateProfileString. SQLGetPrivateProfileString calls functions in the Win32® API to retrieve the requested names of values or data corresponding to a value of the Odbc.ini subkey of the system information."

HTH,
Alexander

>In VFP/MS SQL server application we use registry.pgr to read odbc DSN for primary connection
>And it worked alredy stable for few years in diffrent projects. When we moved into win2000
>, it was very strange problem detected. At 80% cases all worked ok, but in 20% cases failed.
>The reason was, that in 80% of success cases the registry key value was returned, but in 20% of failed
>Cases same program at same computer returned key reference. We made 100 runs at 8 computers and observed same statistic. We moved to NT same code and in did gave this poblem at all.
>Did anybody observed probles in calling api functions , used in registry.prg at win2000
>These ipi just read asci win ini registry file
>and all we need to know database names, sql server names, user and primary passwords from existing DSN
>It is not problem to write new program to do this without calling ipi, but we just curious, what is going on