You are viewing limited content. For full access, please sign in.

Question

Question

database table with field values

asked on September 15, 2015

I can see data for some of the fields in propval table but I can't find data for some of the fields.

I have around 15-20 fields in a table and I can't find data for some of the fields in propval table.

Any idea where can I find that data?

0 0

Answer

SELECTED ANSWER
replied on September 16, 2015 Show version history

It's likely storing it in the num_val column. Give this a try:

SELECT *
  FROM [LFRepoDB].[dbo].[propval] WHERE num_val = '14'

 

 

1 0

Replies

replied on September 15, 2015

I'm not sure what you mean. All field data is in the propval table. What is this other table you mention?

1 0
replied on September 15, 2015

Let me clarify. 

What I meant was, i can see some of the data in propval but some data seems missing.

Data for some of the fields is available in propval but its missing for some other fields.  Hence i thought that their might be another tables holding fields data.

Let me go through the db again (though i have checked and ran valid query many times)

0 0
replied on September 15, 2015
 
 

I don't think I'm telling you anything you don't already know but incase it helps, here's my understanding of where values are stored related to fields.

 

The ID of the field is mapped to the ID of the document,  with the value and type of the data in this table.

 

If it's a multi value field, the pos column will handle the list order or positioning of the values.

 

Field security is in the propacl table.

Further details on the field itself is in the propdef.

And template association is in the propset table.

 

If it's null, it's empty. Otherwise the software will store data into the appropriate data type column.

 
replied on September 16, 2015 Show version history

So here is what I am talking about:

I have a document with one of the field value set as 14 and another filed values set as 15 (screenshot attached). When I use this query:

SELECT *
  FROM [LFRepoDB].[dbo].[propval] WHERE str_val != 'NULL'

I don't get the result for 14 and 15 values.

SELECT *
  FROM [LFRepoDB].[dbo].[propval] WHERE str_val = '14'

This query returns no results.

 

But if I search for a value in for some other fields (e.g a value of Outbound in field called 'Direction' or a value of 008 in a field called CRMCaseID), I do get the value back. So apparently it returning values for some fields but not for all.

Field Values.png
0 0
replied on September 16, 2015 Show version history

Please note, the difference I can see between the values which returns vs the ones which don't is, both the values which I don't get returned are of 'Integer' type fields. Does that make any difference?

While the ones it does return are of List and Text types respectively.

0 0
replied on September 16, 2015

Any suggestion Miruna?

0 0
SELECTED ANSWER
replied on September 16, 2015 Show version history

It's likely storing it in the num_val column. Give this a try:

SELECT *
  FROM [LFRepoDB].[dbo].[propval] WHERE num_val = '14'

 

 

1 0
replied on September 16, 2015

Like Carl says, that's expected behavior. There are different columns for the different field types.

1 0
replied on September 16, 2015

Thanks Carl. That's what I was missing.

0 0
replied on September 16, 2015

Thanks Miruna.

0 0
replied on September 15, 2015
 
 

 

I don't think I'm telling you anything you don't already know but incase it helps, here's my understanding of where values are stored related to fields.

 

The ID of the field is mapped to the ID of the document,  with the value and type of the data in this table.

 

If it's a multi value field, the pos column will handle the list order or positioning of the values.

 

Field security is in the propacl table.

Further details on the field itself is in the propdef.

And template association is in the propset table.

 

If it's null, it's empty. Otherwise the software will store data into the appropriate data type column.

 
1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.