Tuesday, March 20, 2012
Another user has edited the record
I think if it is possible, please show use your error ID, then we can
get more information about the error.
Best Wishes
Wei Ci Zhousql
Another user has edited the record
a ntext field to a text field using a script and it then placed the field at
the end of the field list. when I try to make a change to a record on the f
ront end I get an error tha
t another user has edited the record and must re-edit it. I can then make a
change to the record. If I do a refresh I then get the error again. I then m
oved the text field back into it's original position and the error went away
. Can anyone explain this?Hi Doug:
I think if it is possible, please show use your error ID, then we can
get more information about the error.
Best Wishes
Wei Ci Zhou
Sunday, March 11, 2012
Another profiler question
--=_NextPart_000_006D_01C654BC.18062AC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
The first time I posted it landed under someone else's thread & I wasn't = sure anyone would see it to help me out.
I have a database that's being restored on a monthly basis, but I think = this process is overkill.
The users are using a few tables or whatever to run reports using = Crystal Reports, and accessing tables via MS Access.
What do I profile for to 'see' everything that is being used in this = database so that I can restore only these objects as opposed to the = entire db?
I have only used profiler to do some query statement troubleshooting, = 'Stored Procedure Compelted', but other than that am not proficient with = profiler.
All suggestions are greatly appreciated!!!!
--=_NextPart_000_006D_01C654BC.18062AC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
The first time I posted it landed under = someone else's thread & I wasn't sure anyone would see it to help me = out.
I have a database that's being restored on a = monthly basis, but I think this process is overkill.
The users are using a few tables or whatever = to run reports using Crystal Reports, and accessing tables via MS = Access.
What do I profile for to 'see' everything = that is being used in this database so that I can restore only these objects as = opposed to the entire db?
I have only used profiler to do some query = statement troubleshooting, 'Stored Procedure Compelted', but other than that am = not proficient with profiler.
All suggestions are greatly appreciated!!!!
--=_NextPart_000_006D_01C654BC.18062AC0--How big is your database? If it's small, restoring the database for reporting
may not be a bad practice. Note that you can't just 'restore only these
objects' from the database backup file if you are using SQL Server native
restore.
Linchi
"Jude" wrote:
> The first time I posted it landed under someone else's thread & I wasn't sure anyone would see it to help me out.
> I have a database that's being restored on a monthly basis, but I think this process is overkill.
> The users are using a few tables or whatever to run reports using Crystal Reports, and accessing tables via MS Access.
> What do I profile for to 'see' everything that is being used in this database so that I can restore only these objects as opposed to the entire db?
> I have only used profiler to do some query statement troubleshooting, 'Stored Procedure Compelted', but other than that am not proficient with profiler.
> All suggestions are greatly appreciated!!!!
>|||Actually I am not using Sql Server Native backup software & I do have an
option of restoring single objects.
But to be perfectly honest I didn't want to debate the point, I want to
learn about using profiler to effectively capture this information and
suppose I was looking for a quick answer.
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FAD6A024-8973-4AFC-8F28-75B5ADC2B618@.microsoft.com...
> How big is your database? If it's small, restoring the database for
> reporting
> may not be a bad practice. Note that you can't just 'restore only these
> objects' from the database backup file if you are using SQL Server native
> restore.
> Linchi
> "Jude" wrote:
>> The first time I posted it landed under someone else's thread & I wasn't
>> sure anyone would see it to help me out.
>> I have a database that's being restored on a monthly basis, but I think
>> this process is overkill.
>> The users are using a few tables or whatever to run reports using Crystal
>> Reports, and accessing tables via MS Access.
>> What do I profile for to 'see' everything that is being used in this
>> database so that I can restore only these objects as opposed to the
>> entire db?
>> I have only used profiler to do some query statement troubleshooting,
>> 'Stored Procedure Compelted', but other than that am not proficient with
>> profiler.
>> All suggestions are greatly appreciated!!!!
>>
Thursday, March 8, 2012
Another Major Flaw with Reporting Services!
Where is the text (.txt) export functionality? I don't see any ascii text export mechanism without the .csv extension. Where is actual .TXT file of the reports. How do I get a .txt conversion out of the reports without messing with the .csv files. I would've wanted direct .txt export from the generation mechanism.
This seems extremely basic form of reporting generation. I can't believe you can't get txt report out of reporting services.
Enkh.
Text is universal format so I dont see it as a big deal that it is not available. Any of the formats exported are simply text...|||Well the main problem and is a huge problem is that when you are generating huge reports that neede to be in .txt format and when it is automated to be run every certain while, you would have to convert the .csv to .txt manually everytime. This is huge problem, I mean come on. What do you do when you have to send out thousand and hundred thousand page reports for instance to someone if he only expected to accept the reports in .txt file format. Would you go and convert each file from .csv to .txt. What about formatting? This is really absurd that they don't have .txt conversion and I hope they put out a patch or something that would make this work. Because it's basic format and stuff, doesn't make it less important in anyway. Please Microsoft do something about this, especially the Microsoft reporting services team, at least a patch come on. Please... It's about the quantity of the reports that needs to be in .txt format, and it's not just because I'm being lazy or whatever at all.Please....
Enkh.|||
What do you envision the txt export format to look like? Even with CSV, there are so many tradeoffs. XML export (perhaps with XSLT) will give you the maximum flexibility to tailor the export to meet your requirements.
|||Yes I'm pretty aware with the tradeoffs with the .txt generation of the report. I don't expect the formatting to be so perfect and detailed. Just some basic export function that has everything on the same line and some basic export functionality. In other words, text exporting isn't meant to be really nice report, since they are expecting something decent readable as a text so that it takes less space on their hard drive. If they want perfect report, they can do the pdf or the excel version. I would say just basic decent .txt dump of the report is extremely useful to me and other I think. The reason why I say this is because, when thousands of pages of reports are automated and generated, person doesn't have to manually open and save the .csv or .xsl or whatever to .txt format.
Please feedback. Come on automatic .txt dump of the report with decent layout, not glamorious and exact.
Enkh.
|||So, if you abstract yourself from the fact that a csv extension suggests comma-separated output and customize the CSV renderer in rsreportserver.config as shown here, do you think that your requrements are met?
<Extension Name="CSV" Type="Microsoft.ReportingServices.Rendering.CsvRenderer.CsvReport,Microsoft.ReportingServices.CsvRendering">
<Configuration><DeviceInfo>
<Encoding>ASCII</Encoding>
<FieldDelimiter>Whatever delimiter my users want</FieldDelimiter>
<!--more device info params if needed-->
</DeviceInfo></Configuration>
</Extension>
If you choose export to a file share instead of e-mail in your subscription, you can choose the name of the file by not checking the check box underneath the file name.
So you can call your file MyFile.txt if you wish, it doesn't have to be called MyFile.csv
|||Ok that's great, but the bottom line is that there should be another feature in the export dropdown for text, and text generation with some decent layout except the coma delimited text export. I mean something close to the actual report. I think text generation feature is fundamental to reporting services more than anything that I know now.
Enkh.
|||If it bothers you that much then write your own renderer. Then maybe we could all benefit from you fixing this "fundamental" issue.|||I'm still not sure what you mean about "text" generation. Are you talking about formatted ASCII? In this case, we would take a definition and map it to a 132 column output and replace the object positioning with tabs or spaces? If this is the case, the only scenarios that I would think this is useful for is either sending to a dot matrix printer (most printers are PostScript or PCL based these days) or embed the text in an e-mail for e-mail clients that can't display HTML output. If this is the scenario, I can't say that we have gotten lots of requests for this.|||The thing I'm saying about "text" generation is this
1. The generated file should be in ".txt" format like "Some report.txt". So it should be downloadable ".txt" file. That's why I suggested that there should be another field in the export dropdown that says like "text" just like pdf, excel etc. Basically another format added to the export mechanism for ASCII .txt exporting.
2. In terms of layout, the layout should be different from every field placed in each column. So that means basically, if the data for the report is pulled like this from the query
columna columnb columnc columnd
a asdf df sdf
should come out like this on the report for instance (just like its design layout)
columna columnc
columnb columnd
a df
asdf sdf
So in other words, it would be exact .pdf or excel dump layout in .txt with no coma delimited list. It should be as readable as possible. So the exact design layout dumped just like that as .txt. Basically no technical and basically unreadable layout.
3. The format of the report will be plain ASCII, so that means simple and basic ".txt" file. If it's viewable and ok showing up in notepad, it's ok with me. Just basic .txt file of the report with the exact same design layout as the report (like how it shows up as in the pdf version) is what I'm saying with no special rtf, no .csv or any special formatting, techniques or languages at all.
|||I definitely agree with ENKHT.
I have the same issue. One of our external partners expect a txt file with specfic columns and associated data.
In other words, they read each line and know exactly where the start and end point of each column. And having a txt extension is very basic. When I tell others in my team, they can't believe there is no txt extension. That's a big problem for us. We were looking forward to using Reporting Services to replace Cognos, but now I am not to sure. Its a case by case project.
Can someone please explain the exact steps to take to acquire a txt extension file ?
Another Major Flaw with Reporting Services!
Where is the text (.txt) export functionality? I don't see any ascii text export mechanism without the .csv extension. Where is actual .TXT file of the reports. How do I get a .txt conversion out of the reports without messing with the .csv files. I would've wanted direct .txt export from the generation mechanism.
This seems extremely basic form of reporting generation. I can't believe you can't get txt report out of reporting services.
Enkh.
Text is universal format so I dont see it as a big deal that it is not available. Any of the formats exported are simply text...|||Well the main problem and is a huge problem is that when you are generating huge reports that neede to be in .txt format and when it is automated to be run every certain while, you would have to convert the .csv to .txt manually everytime. This is huge problem, I mean come on. What do you do when you have to send out thousand and hundred thousand page reports for instance to someone if he only expected to accept the reports in .txt file format. Would you go and convert each file from .csv to .txt. What about formatting? This is really absurd that they don't have .txt conversion and I hope they put out a patch or something that would make this work. Because it's basic format and stuff, doesn't make it less important in anyway. Please Microsoft do something about this, especially the Microsoft reporting services team, at least a patch come on. Please... It's about the quantity of the reports that needs to be in .txt format, and it's not just because I'm being lazy or whatever at all.Please....
Enkh.|||
What do you envision the txt export format to look like? Even with CSV, there are so many tradeoffs. XML export (perhaps with XSLT) will give you the maximum flexibility to tailor the export to meet your requirements.
|||Yes I'm pretty aware with the tradeoffs with the .txt generation of the report. I don't expect the formatting to be so perfect and detailed. Just some basic export function that has everything on the same line and some basic export functionality. In other words, text exporting isn't meant to be really nice report, since they are expecting something decent readable as a text so that it takes less space on their hard drive. If they want perfect report, they can do the pdf or the excel version. I would say just basic decent .txt dump of the report is extremely useful to me and other I think. The reason why I say this is because, when thousands of pages of reports are automated and generated, person doesn't have to manually open and save the .csv or .xsl or whatever to .txt format.
Please feedback. Come on automatic .txt dump of the report with decent layout, not glamorious and exact.
Enkh.
|||So, if you abstract yourself from the fact that a csv extension suggests comma-separated output and customize the CSV renderer in rsreportserver.config as shown here, do you think that your requrements are met?
<Extension Name="CSV" Type="Microsoft.ReportingServices.Rendering.CsvRenderer.CsvReport,Microsoft.ReportingServices.CsvRendering">
<Configuration><DeviceInfo>
<Encoding>ASCII</Encoding>
<FieldDelimiter>Whatever delimiter my users want</FieldDelimiter>
<!--more device info params if needed-->
</DeviceInfo></Configuration>
</Extension>
If you choose export to a file share instead of e-mail in your subscription, you can choose the name of the file by not checking the check box underneath the file name.
So you can call your file MyFile.txt if you wish, it doesn't have to be called MyFile.csv
|||Ok that's great, but the bottom line is that there should be another feature in the export dropdown for text, and text generation with some decent layout except the coma delimited text export. I mean something close to the actual report. I think text generation feature is fundamental to reporting services more than anything that I know now.
Enkh.
|||If it bothers you that much then write your own renderer. Then maybe we could all benefit from you fixing this "fundamental" issue.|||I'm still not sure what you mean about "text" generation. Are you talking about formatted ASCII? In this case, we would take a definition and map it to a 132 column output and replace the object positioning with tabs or spaces? If this is the case, the only scenarios that I would think this is useful for is either sending to a dot matrix printer (most printers are PostScript or PCL based these days) or embed the text in an e-mail for e-mail clients that can't display HTML output. If this is the scenario, I can't say that we have gotten lots of requests for this.|||The thing I'm saying about "text" generation is this
1. The generated file should be in ".txt" format like "Some report.txt". So it should be downloadable ".txt" file. That's why I suggested that there should be another field in the export dropdown that says like "text" just like pdf, excel etc. Basically another format added to the export mechanism for ASCII .txt exporting.
2. In terms of layout, the layout should be different from every field placed in each column. So that means basically, if the data for the report is pulled like this from the query
columna columnb columnc columnd
a asdf df sdf
should come out like this on the report for instance (just like its design layout)
columna columnc
columnb columnd
a df
asdf sdf
So in other words, it would be exact .pdf or excel dump layout in .txt with no coma delimited list. It should be as readable as possible. So the exact design layout dumped just like that as .txt. Basically no technical and basically unreadable layout.
3. The format of the report will be plain ASCII, so that means simple and basic ".txt" file. If it's viewable and ok showing up in notepad, it's ok with me. Just basic .txt file of the report with the exact same design layout as the report (like how it shows up as in the pdf version) is what I'm saying with no special rtf, no .csv or any special formatting, techniques or languages at all.
|||I definitely agree with ENKHT.
I have the same issue. One of our external partners expect a txt file with specfic columns and associated data.
In other words, they read each line and know exactly where the start and end point of each column. And having a txt extension is very basic. When I tell others in my team, they can't believe there is no txt extension. That's a big problem for us. We were looking forward to using Reporting Services to replace Cognos, but now I am not to sure. Its a case by case project.
Can someone please explain the exact steps to take to acquire a txt extension file ?
Another easy question
For example
CREATE TRIGGER test ON [Table_1]
FOR DELETE
AS
..... export to a text file someting like this:
Date + TableName + UserName + Record with will be deleted
How can I export a single record to a text file ?
Sorry for my englishWell .. use xp_cmdshell and echo for the same|||Please an example will be usefull for me...|||CREATE TRIGGER test ON MyTable
FOR DELETE
AS
BEGIN
DECLARE @.MyString varchar(255)
SELECT @.MyString=
"ECHO "
+convert(varchar(20), getdate(), 0)
+" MyTable "
+ convert(varchar(10), MyKey)
+ user_name()
+ ">> C:\temp\log.txt"
exec xp_cmdshell @.myString
END
Wednesday, March 7, 2012
Another " Error: 4813 Expected the text length in data stream - "
distributions now fails with the following error:
The process could not bulk copy into table '"texttab"'.
Expected the text length in data stream for bulk copy of text, ntext,
or image data.
(Source: DESTINATION_SERVER (Data source); Error number: 4813)
Function sequence error
(Source: ODBC Driver Manager (ODBC); Error number: S1010)
The last column of the table in error is type "text". If we lower the
number of the "BCPBatchSize" in the distribution agent profile, more
rows get copied before the error occurs - but there are too many other
very large tables in the snapshot to use that as a go-around.
As suggested in a previous post, we cannot change the table structure
because it is a third-party developed product.
When we use the -UseInProcLoader option in the dist agent, it creates
another error.
We're running SQL Server 2000 8.00.760
Thanks for any ideas.
remove the text column and replicate the remaining table. Use another method
to synchronize the text column, such as using a trigger to write to an audit
table. Have DTS read this audit table at regular intervals and then update
the text column between the publisher and subscriber. In many topologies you
will find that the text/image column is highly static.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Dean" <dpichotto@.cse-insurance.com> wrote in message
news:1120071435.407646.302670@.g49g2000cwa.googlegr oups.com...
> After working for over a year, one of our snapshot replication
> distributions now fails with the following error:
> The process could not bulk copy into table '"texttab"'.
> Expected the text length in data stream for bulk copy of text, ntext,
> or image data.
> (Source: DESTINATION_SERVER (Data source); Error number: 4813)
> Function sequence error
> (Source: ODBC Driver Manager (ODBC); Error number: S1010)
> The last column of the table in error is type "text". If we lower the
> number of the "BCPBatchSize" in the distribution agent profile, more
> rows get copied before the error occurs - but there are too many other
> very large tables in the snapshot to use that as a go-around.
> As suggested in a previous post, we cannot change the table structure
> because it is a third-party developed product.
> When we use the -UseInProcLoader option in the dist agent, it creates
> another error.
> We're running SQL Server 2000 8.00.760
> Thanks for any ideas.
>
|||Thanks very much for your reply.
Wow - how twisted! I wonder if using ftp for the distribution would get
around this...