If you have to write an ado db recordset into an Excel worksheet, you have two basic options.
Either you write a recordset object using Excel API function copyFromRecordset or you write the data implementing an own method looping through all records.
However calling the function copyFromRecordset is pretty fast compared to looping through all records, it opposes the risk of incorrectly formatted data in a target worksheet. Root cause for this is the often failing attempt of ADO to guess a data type of a column in a source worksheet based on the first few records.
You can switch some optional parameter in a connection string called IMAX in order to have ADO take all records of a field in a recordset into account before guessing a field type, but this will lead only to incredible bad performance.
On top of that ADO is still likely to fail in guessing a field type of an Excel column even, if you use IMAX.
Excel is not a database and therefore it is not possible to declare a datatype for a column. Out of own bad experiences with different formats causing SQL queries using Joins to fail or deliver invalid results I strongly recommend to use copyFromRecordset only in a very controlled environment or rarely, if at all.
If you think about trying to set the data type of a field before writing its records into an Excel sheet or before querying data in a source sheet, forget it. This won't work either, since ADO will not allow you to set the correct data type explicitly in Excel although its API delivers functions for this purpose.
Instead you could use the following method implemented in Excel VBA.