When get data between two time on date time column, it does not return any rows – ASP.NET / C#

So, a few things:

Don’t wrap long lines of code, they are VERY prone to errors.

Looking at your SQL, you have this:

  select datelogged AS EntredDatetime, Doc_type AS OrderType, Printer_name,
  BranchID AS BranchCode, Status, id from Print_Report 
  where cast(datelogged as date)=@datelogged
  and and FORMAT(CAST(datelogged AS DATETIME), 'HH:mm')>'@FromTime'
  AND FORMAT(CAST(datelogged AS DATETIME), 'HH:mm')<@ToTime"

Note how easy now we see "and and" in your SQL.

And don’t do those casts in the SQL, since it messy, but such expressions can’t be indexed, and they will run turtle slow.
(besides, it makes the SQL rather a mess to work with).

next up:
consider moving the in-line SQL out to a stored procedure, but even better (and less effort and work) is to use a view, and thus "less" work then a stored procedure, you can use the query builder/designer, and EVEN better is multiple routines can use that one "view". You still use in-line SQL, but only say

 select * from vPrint_Report
 WHERE datelogged is BETWEEN @dtStart AND @dtEnd";

next up:

Don’t use add with value – use STRONG typed parameter’s.

next up:

While using Parmaters.Add("some parm", "some value") is deprecated, since the 2nd parameter can be confused with int as dbtype?

using typed parameter with "ADD" IS NOT deprecated!!!, and in fact I recommend using

 .ADD("@ParmName", sqlDbType.int).Value = 

Again, above format is NOT deprecated, only the overload with a non dbtype for 2nd parameter in above is deprecated!!!

Next up:

You don’t show where that connection object is created. DO NOT try to make some global scoped connection object. While before the "web days", for performance, yes, often we "persisted" a connection object, but with web based, there is a automatic "connection" pool, and thus the standard is to re-create the connection’s each time, and LET THE SYSTEM AUTOMATIC dispose for you. By doing this, you leverage the "automatic" connection system in .net web based system.

Re-creating the connection object each time is NOT a performance hit, since the connection pool will "find" and use cached connection – it runs fast – feel free to re-create connection object each time.

And how do you LET the system manage this for you? Why of course you ALWAYS wrap that code in using blocks. In your example, you ONLY dispose of the connection when code errors, but not on success.

next up:

As noted, don’t try to parse out, or convert the date, and date time in the SQL, but supply STRONG types for start and end date (both with time). Not only is such code less of a mess, but it also a "tiny" bit of work in the code, but the SQL becomes VAST VAST less messy. So, we trade a "wee bit" of code for a HUGE bonus of nice clean SQL.

So, lets take all of the above lessons, and thus we get this now:

public DataTable GetDataForSearch(string datelogged, string FromTime, string ToTime)
{

    DataTable dt = new DataTable();
    string strCon = Properties.Settings.Default.TEST4; // change to YOUR conneciton

    using (SqlConnection conn = new SqlConnection(strCon))
    {
        string strSQL =
            @"select datelogged AS EntredDatetime, Doc_type AS OrderType, 
            Printer_name, BranchID AS BranchCode, Status, id
            FROM Print_Report
            WHERE datelogged is BETWEEN @dtStart AND @dtEnd";

        DateTime dtDate = DateTime.Parse(datelogged);
        DateTime dtFromTime = DateTime.Parse(FromTime);
        DateTime dtToTime = DateTime.Parse(ToTime);

        DateTime dtStart = 
          dtDate.Add(new TimeSpan(dtFromTime.Hour, dtFromTime.Minute, dtFromTime.Second));

        DateTime dtEnd =
          dtDate.Add(new TimeSpan(dtToTime.Hour, dtToTime.Minute, dtToTime.Second)); 

            
        using (SqlCommand cmd = new SqlCommand(strSQL, conn))
        {
            cmd.Parameters.Add("@dtStart", SqlDbType.DateTime).Value = dtStart;
            cmd.Parameters.Add("@dtEnd", SqlDbType.DateTime).Value = dtEnd;

            try
            {
                conn.Open();
                dt.Load(cmd.ExecuteReader());
            }
        }
    }
    return dt;
}

So, note how we let the system "close" the connection’s, and dispose of it. And even if the code errors out, even when NOT trapped, the connection and command object will be correctly disposed and managed for you – IN ALL cases!!!

Also, note how a bit of effort on the code side to get STRONG TYPED date start and end, thus makes the SQL part a whole lot less work, but MORE important also means that we use + enjoy STRONG typed values for the parameter’s, and we enjoy use of high speed indexing.