The code that i developed works with other i2c device but not with DLVR sensor(which proves the code is good)
[My emphasis above.]
FYI the emphasised statement above is not true. This is a common troubleshooting fallacy, because it assumes all I²C devices behave in the same way.
Some I²C slaves are more, or less, tolerant to the exact behaviour of an I²C master. It is possible to have software (or hardware) bugs / limitations which only affect some devices, or which require specific I²C master programming. Therefore your statement that your code has been proved good because one type of I²C device works, is false. (Of course your code might, indeed, be suitable for both of your devices - but your test doesn't prove that.)
Any idea how to debug this issue?
There are many possible techniques, depending on your available equipment, skills, experience, time, money etc.
Assuming that you have suitable test equipment, then using a simplified Kepner-Tregoe ATS (Analytical Trouble Shooting) approach, you have a very nice "IS" (i.e. problem) / "IS NOT" (i.e. no problem) pair of equivalent tests:
IS (i.e. test case shows the problem)
using a FTDI's UM232H usb-i2c adapter [...] i couldn't be able to communicate with DLVR sensor.
IS NOT (i.e. test case shows no problem)
i can able to communicate with the same DLVR sensor using Aardvark adapter.
[The ATS methodology, while too complex to explain in full here, includes comparing pairs of "IS" (i.e. is showing a deviation from correct behaviour = problem) vs. "IS NOT" (i.e. is not showing a deviation from correct behaviour = no problem) among other things.]
So gather oscilloscope traces (ideally), or logic analyser traces (if an oscilloscope is not available) from the "IS" (i.e. problem) and the "IS NOT" (i.e. no problem) test cases and compare the traces. That is a starting point.
Since one test works and the other doesn't work, then there must be one or more differences in what happens on the I²C bus, between the two test cases.
Find the difference(s)!
The next steps depend on what you find...
Note that logic analyser traces can't show some electrical problems, and this can mislead you in some situations. At least starting with a 'scope will allow you to confirm and validate the I²C waveform shape (rise/fall times), voltage levels (i.e. pull-ups to correct voltage for the devices on that bus) etc. If all of that is confirmed correct, and the problem is definitely at an I²C protocol level, rather than electrical level, then a logic analyser might be good enough for further troubleshooting.