Showing posts with label storing. Show all posts
Showing posts with label storing. Show all posts

Thursday, March 29, 2012

Data Storing Problem......

Hi everyone,

I have some data which is in korean Language and i want to store that data in sql server 2000 table's row.But i am not able to store it.

When i try to store it then it display me square box in table.

Does anybody have any idea about this matter?

Plz reply me back as soon as possible.

Thanks

---Nimesh Patel

Please check out Books On Line for SQL Collations. Setting the collation level allows you to store data in different languagues.|||

Collations have nothing to do with what you can or can't store. Collations are the rules that define the order of alphabets, which is important for sorting.

Are the columns that you are storing the data into defined as nvarchar, nchar, or ntext?

After pulling out the data from the database, are you displaying it in a font that actually has those characters?

|||Embarrassed I think I need to check out the BOL first. thanks for the correction Motley and good to see you back. Its been kinda dull here lately..|||Good to see you are still around as well ;-)|||Yes.. been fighting the battle all aloneSmile|||You've never been alone, you've just been doing such a great job that I rarely have to say anything anymoreBig Smile

Thursday, March 22, 2012

Data schema for storing arbitrary order

Currently this is purely hypothetical, though I'm semi-considering something
like this for part of a current project. I'm wondering how to apply a
pseudo-order to a set of data.
To give an example, if you were storing Service Ranks, which were
referenced by the service personnel you stored in the database :-
(... indicates other ranks in-between)
Rear Admiral
...
Admiral
...
Captain
...
Ensign
You store the data as a 2 column table, RankID (unique system-generated eg
Identity(1,1)) and RankName (varchar(50) perhaps).
So you now want to produce a report, that lists the personal in order from
highest rank to lowest rank. As far as the software user is concerned, if a
rank was missing, they would just enter it, tell the system what rank it was
below/above, and it would be stored. But how best to store the list in the
database, given that a new item could be inserted anywhere in the list? You
can't sort alphabetically, because the ranks aren't alphabetically ordered.
You can't trust an auto-generated ID, because that would put most recent
additions at the bottom, earliest at the top.
My current thought is to add a new column to the items - RankPos (integer) -
with an arbitrary (x) between the items (so first rank would be 10, fourth
rank down would be 40, the rank below it would be 50 etc)... if a rank is
inserted between the two, I'd give the new rank 45, and then run an update
once in a while (or if the numerical gap was used up) that would re-number
this column so there was an gap (x) of 10 again. But, is there a better way?
As I said, just wondering at the moment, but not the first time. I seem to
be stuck in the record groove, coming back to the above way each time I
think about it.
Yours,
Ann-Mariethat is one way....to add a "SortOrder" or "SortSequence" column
the other way is to implement this as a linked list or dual linked list.
Where each individual record keeps track of who is above and who is below
them.
just food for thought.
Greg Jackson
PDX, Oregon|||"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:e7VFu98LFHA.2796@.tk2msftngp13.phx.gbl...
> that is one way....to add a "SortOrder" or "SortSequence" column
> the other way is to implement this as a linked list or dual linked list.
> Where each individual record keeps track of who is above and who is below
> them.
> just food for thought.
> Greg Jackson
> PDX, Oregon
>
From the software development background, yes, I would agree. But when it
comes to SQL, but wouldn't I then have a problem doing a simple query to get
the personnel returned 'ORDER BY {rank}'. Echoes of the adjacency tree
storage vs. nested-set tree storage problems and discussion come to mind.
That said, thanks for your reply,
Ann-Marie

Tuesday, February 14, 2012

data format of XML data in datafile generated by bcp -n

Hi,

The XML column data stored in the data file generated by using bcp -n is in two different formats. one is storing the actual length of the data prefixed by an 8 byte length infront of the data; the other one whithout the prefixed length but "FEFFFFFFFFFFFFFFFC030000" infront of the data.

Could any body please tell me what the binary means?

Thanks,

Lijie

In native mode, the length prefix for xml data is of 8 bytes. There are 3 variations of this length:

a) If it's 0xFFFFFFFFFFFFFFFF then the column value is NULL

b) If it's 0xFFFFFFFFFFFFFFFE (FEFFFFFFFFFFFFFFF in little endian), that means the data is stored as chunks, so following this length indicator there will be chunks of xml column data with 4 bytes length prefix and then chunk data and so on, until a chunk is hit whose length is specified by 0x00000000 indicating end of column data.

c) Length prefixed data, for any value other than (a) and (b) this indicates the actual length of data.

Thanks

Waseem Basheer

SDE - Data Programmability Group

Microsoft Corp.

data format of XML data in datafile generated by bcp -n

Hi,

The XML column data stored in the data file generated by using bcp -n is in two different formats. one is storing the actual length of the data prefixed by an 8 byte length infront of the data; the other one whithout the prefixed length but "FEFFFFFFFFFFFFFFFC030000" infront of the data.

Could any body please tell me what the binary means?

Thanks,

Lijie

In native mode, the length prefix for xml data is of 8 bytes. There are 3 variations of this length:

a) If it's 0xFFFFFFFFFFFFFFFF then the column value is NULL

b) If it's 0xFFFFFFFFFFFFFFFE (FEFFFFFFFFFFFFFFF in little endian), that means the data is stored as chunks, so following this length indicator there will be chunks of xml column data with 4 bytes length prefix and then chunk data and so on, until a chunk is hit whose length is specified by 0x00000000 indicating end of column data.

c) Length prefixed data, for any value other than (a) and (b) this indicates the actual length of data.

Thanks

Waseem Basheer

SDE - Data Programmability Group

Microsoft Corp.