Control names of fields when exporting to CSV

My query returns fields that have spaces in the names, for example:

select o.OrderID as 'INVOICE NUMBER', etc..

When I created the DataSet for this query in report designer, it changed all spaces in the field names to underscores, i.e. INVOICE_NUMBER.

This report must be exported to CSV, and the names of the fields (first row in csv) must have the spaces, not underscores. But it appears RS uses the field names (not the names in the column headers of the report table control) as the field names. Is there any way for me to force the field names in the first row of the csv to something other than the field names in the DataSet?

Thanks!

I think I you should be able to rename the column headers to change the results in the CSV file.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

ALFKI,

You can go to the column properties data output tab and enter the "Element Name" and select output as "Yes" this is how I can my export to csv files.

Ham

|||

should read

"how I change my export column names in the csv files"

|||Thanks - the only problem is, Element Name cannot contain a space , hence the underscores. Oh, well...|||

ALFKI,

Sorry, Yes, you are still bounded by the textbox property field names. You could not for instance name a textbox "My Textbox Value" is must be My_TextBox_Value. I mistaken thought you were just trying to rename the field.

Ham

Constraing Question

Converting a program from VS03/MSDE to VS05 Pro/SQL Express...

In VS05, in Datasouse tab, "edit with Dataset with designer", click on relation between two tables, choose "edit relation" from context menu, under "Choose what to create" there are 3 radio buttons:

- Both relation of foreign key constraint

- Foregin Key constraint only

- Relation only

I have discovered that the choice made dramatically affects the Fill order of tables. In general I use the first one.

I would like more information on these options than I have been able to find in help.

Here is the specific issue (simplified)...two tables UserID -> Recordings. In a specific senerio, I must fill recordings table first, and use the Foreign Key to back track to get the UserID and fill the UserID table, which means for the Recordings table I use the radio button Relation only (otherwise I get a constraint error)

Would it be better to use the first radio button, "Both relation of foreign key constraint", but relax constraints when filling Recordings/UserID tables, and then enfore constraints again when done? Which is the better way?

Thanks for your help

Bob

hi Bob,

selecting the 1st radio performs both a database relation and an application code relation...

the 1st one is an actual object in the underlying database, a constraint object of foreign key..

the 2nd one only is a "soft" relation, an object not present in the database as a real constraint, but residing "in memory" in the actual "in memory database" represented by the dataset, which should be performed after the "fill" has been finished validating (if accordingly set) eventual constraints... but this only client side, in the "in memory database"...

obviously, better protection is set when the actual constraint is defined in the database as this is the place of the real "storage", where data should alway be "correct" and consistent...

as you are loading data from a "protected" source, the database with enforced fk constraint, it's a good idea to relax constraints when filling, as you already know they would be satisifed and enforced by the underlying datasource, so you can improve performance enforcing .Net relation's constraints after the initial filling, to protect application code in the disconnected scenario we all are working.. this way, erratic handling would be reported immidiatly without having to wait for the "sync" roundtrip to the actual datasource...

regards