Do SQL Server's developers even know what the datetime datatype is?

Just a bit of a rant here...
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>

Do SQL Server's developers even know what the datetime datatype is?

Just a bit of a rant here...
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>

Distributor to Subscriber History

I am using publisher as 2005 and subscriber as 2000. I am getting
Uninitialized Subscription. When I double click I don't see any message on
Distributor to Subscriber Histor. Where as I can see message for one of the
subscriber which is 2005.
Is that is do with 2000?
Nita
What type of repl? Sanpshot/Trans/Merge?
did you run your snapshot agent after adding subscription to 2000 svr?
Did your distribution agent push snapshot?
Try running Profiler on subscriber to pick up activity from distributor to
help troubleshoot.
ChrisB MCDBA
MSSQLConsulting.com
"NitaDBA" wrote:

> I am using publisher as 2005 and subscriber as 2000. I am getting
> Uninitialized Subscription. When I double click I don't see any message on
> Distributor to Subscriber Histor. Where as I can see message for one of the
> subscriber which is 2005.
> Is that is do with 2000?
> --
> Nita

Distribution Agent History Clean Up Fails

Hi everyone.
i'm using sql database 7.0 setup for merge replication.suddenly i found out
that the "Agent History Cleanup:Distribution" had a red x mark.When i
examined,it shows that the agent did not run on its specied running
schedule.Even if i run it manually,still it won't work. When i check the
history of the agent why it fails to run it state their that:
could not find the index entry for RID '361526d0688a801749800300101801000'
in index page (1:1084), index ID 0, database 'distribution'. [SQLSTATE HY000]
(Error 644). The step failed.
Is this error will affect the replication process of my server?How can i fix
this one?
I will really appreciate any help you could give and thanksin advance.
I'd run dbcc checkdb on the distribution database.
Also consider dbcc dbreindex on each table in the distribution database.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||hi sir.first i want to thank you for your response.
I still have some query about my problem sir.
I already run a dbcc checkdb on my distribution database,but unfortunately
it still not solve my problem.
The dbcc checkdb returns a result that "checkdb found 0 allocation errors
and 0 consistency errors in my database".
Is there other way to resolve this problem sir?
Will this miscellaneous agent error affects my database replication?
Thank you and more power.
"Paul Ibison" wrote:

> I'd run dbcc checkdb on the distribution database.
> Also consider dbcc dbreindex on each table in the distribution database.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||OK - then please try running dbcc dbreinxdex on all tables in the
distribution database and we'll see if this fixes it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .