Mining structure has to contain at least 2 mining models to see their accuracy charts?

Hi ,all here,

Thank you very much for your kind attention.

I just found that I am not able to view the accuracy chart for my mining model. The error message is: no mining models are selected for comparision. Which is quite strange.

Any guidance? thank you very much.

With best regards,

Yours sincerely,

Can you provide more details? The only scenario I can think of where this would happen is where the first model was a clustering model that had no predictable attributes.|||

Hi, Jamie,

Yes, my mining model is clustering model. So as you mentioned, seeing the accuracy chart of clustering model is restricted in there? If so, what's the resolution? Thank you very much for your further guidance.

With best regards,

Yours sincerely,

|||

The accuracy chart is only useful if your model has a predictable attribute (column), and the accuracy of the prediction can be evaluated against some test data. If your clustering model does not have a predictable attribute, the accuracy chart cannot be used.

|||

Hi, Bogdan, thank you very much for your guidance.

So in what way can we verify if the clustering model is good enough or not?

With best regards,

Yours sincerely,

Mining Accuracy Chart, predictable column in nested tables

In the Mining Accuracy Chart, the predictable columns of nested tables does not show up in the "Select predictable mining model columns to show in the lift chart" table. The "Predictable column name" is empty.

Predictable columns in the case table shows up, but not the predictable columns in the nested table. What am I missing?

-Young K

The accuracy chart currently does not support predictable columns in nested tables.

Migration of Teradata and DB2 Timestamp fields.

I am trying to migrate timestamp fields in Teradata and
DB2 to SQL server. The problem is that Teradata and DB2
store timestamps to an accuracy of 1 microsecond, while
SQL Server stores it to the nearest 3.33 milliseconds
(the datetime datatype). The original accuracy needs to
be preserved as the columns are part of the primary key.
Is there an equivalent datatype in SQL Server or a quick
workaround for this problem? Date / Time functions need
to be performed on these columns.
There is no datatype in SQL Server that has a precision of 1 millisecond. I
can suggest 3 different workarounds:
- Store the timestamp in a CHAR(23) column in format
yyyy-mm-ddThh:mi:ss.nnn. You CONVERT this to and from datetime with style
126. Note that the precision will go back to 3.33 milliseconds when you
convert to datetime. This uses 23 bytes of storage.
- Store the timestamp as a UNIX timestamp (milliseconds since 1970-1-1) in a
BIGINT column. This uses 8 bytes of storage.
- Store the timestamp in 2 columns, one is a SMALLDATETIME (precision 1
minute), the second one is a INT, to store the number of milliseconds. This
uses 8 bytes of storage. (You can also use a SMALLINT if you want to save 2
bytes, but then you have to handle negative milliseconds.
Whichever is the most convenient of course depends on the calculations you
are going to do with it.
Jacco Schalkwijk
SQL Server MVP
"Arumugam" <arumugam@.optusnet.com.au> wrote in message
news:de3401c43bd6$5e60f870$a501280a@.phx.gbl...
> I am trying to migrate timestamp fields in Teradata and
> DB2 to SQL server. The problem is that Teradata and DB2
> store timestamps to an accuracy of 1 microsecond, while
> SQL Server stores it to the nearest 3.33 milliseconds
> (the datetime datatype). The original accuracy needs to
> be preserved as the columns are part of the primary key.
> Is there an equivalent datatype in SQL Server or a quick
> workaround for this problem? Date / Time functions need
> to be performed on these columns.

Migration of Teradata and DB2 Timestamp fields.

I am trying to migrate timestamp fields in Teradata and
DB2 to SQL server. The problem is that Teradata and DB2
store timestamps to an accuracy of 1 microsecond, while
SQL Server stores it to the nearest 3.33 milliseconds
(the datetime datatype). The original accuracy needs to
be preserved as the columns are part of the primary key.
Is there an equivalent datatype in SQL Server or a quick
workaround for this problem? Date / Time functions need
to be performed on these columns.There is no datatype in SQL Server that has a precision of 1 millisecond. I
can suggest 3 different workarounds:
- Store the timestamp in a CHAR(23) column in format
yyyy-mm-ddThh:mi:ss.nnn. You CONVERT this to and from datetime with style
126. Note that the precision will go back to 3.33 milliseconds when you
convert to datetime. This uses 23 bytes of storage.
- Store the timestamp as a UNIX timestamp (milliseconds since 1970-1-1) in a
BIGINT column. This uses 8 bytes of storage.
- Store the timestamp in 2 columns, one is a SMALLDATETIME (precision 1
minute), the second one is a INT, to store the number of milliseconds. This
uses 8 bytes of storage. (You can also use a SMALLINT if you want to save 2
bytes, but then you have to handle negative milliseconds.
Whichever is the most convenient of course depends on the calculations you
are going to do with it.
Jacco Schalkwijk
SQL Server MVP
"Arumugam" <arumugam@.optusnet.com.au> wrote in message
news:de3401c43bd6$5e60f870$a501280a@.phx.gbl...
> I am trying to migrate timestamp fields in Teradata and
> DB2 to SQL server. The problem is that Teradata and DB2
> store timestamps to an accuracy of 1 microsecond, while
> SQL Server stores it to the nearest 3.33 milliseconds
> (the datetime datatype). The original accuracy needs to
> be preserved as the columns are part of the primary key.
> Is there an equivalent datatype in SQL Server or a quick
> workaround for this problem? Date / Time functions need
> to be performed on these columns.