With a database size of almost 2 GB, I run the 'truncate table eventlog command' which completes successfully, but the database size only decreases by about 10 MB so stays too large - indeed the number of rows in the eventlog table is minimal, but the otehr tables in this database don't show such an amount of tables large enough to cause the size issue either. What could be the reason and how can I reduce it (possibly truncating another table but then which one, how could I determine which is too large and needs truncating?).
Please forgive the elementary nature of my question, but could someone please explain the differences between these two database backup types:
1. Log backup 2. Log backup no truncate
From what I understand and have read, the "no truncate" backup method keeps the entire transaction log indefinitely. Using the truncation method, the transaction log is either 1) compressed or 2) cleaned up so that any completed transactions are removed from the log. Which one of these is true?
And, for the big question: is it better to run a backup of the transaction log with truncation or not? Our current backup scheme is similar to the following:
Full backup every 24 hours transaction log backup every hour with no truncation
Should we insert a truncation backup somewhere in here? What is the danger of removing (or compressing) parts of the transaction log? Will this affect the restore process?
I would like to add leading zeros in the date. Thsi is my existing procedure, it adds leading zeros, but it formats using "yyyy/mm/dd", instead of "yyyy-mm-dd" Select Id, Title, CONVERT(VARCHAR(10), ModifiedON, 111) --CAST(YEAR(ModifiedOn) AS VARCHAR(4))+'-'+CAST(MONTH(ModifiedOn) AS VARCHAR(2))+'-'+CAST(DAY(ModifiedOn) AS VARCHAR(2))as ModifiedOn From ActiveAds Where Row between @startRowIndex And @endRowIndex
I have a situation where I need to display an integer with leading zeros, with a defined length. Example, 43 appears as 00043 when the length is 5 and 000043 when the length is 6.
I tried using "=Format(Fields!DirID.Value.ToString)" with different variations to no avail.
mssql 2000, asp.net(vbscript) How am i able to trim leading zeros? Right now i have two values:00000005 500000010 1000000015 15..... etc... how do i write a query where i can select an argument where 5 = 0000005? the column with 00000005 is varchar and5 is numeric
I have a web application/database that is a sort of rating system. right now it accepts 1-5 and then averages all the scores on the results page of my application according to a specific date range. Now here is the problem: My people want to be able to input a 0 or N/A into the application. Now how can I make the averages correct by skipping the 0s and just averaging the other numbers?? here is a sample of my sql statement.
Dim BIOpbl As New Data.SqlClient.SqlCommand("SELECT pbl1v FROM BioPsychSocial WHERE (resident LIKE @resident) AND (date BETWEEN @date AND @date2)", conn) BIOpbl.Parameters.AddWithValue("resident", ResidentList.SelectedValue) BIOpbl.Parameters.AddWithValue("date", Calendar1.SelectedDate) BIOpbl.Parameters.AddWithValue("date2", Calendar2.SelectedDate) please help, thanks -eric
I have a problem while importing data from Excel to SQL Server.The leading zeros in data get truncated.Even if I try and change the excel data column as 'Text' and copy paste the data back into the Text column, the problem persists.Does any one have any thoughts about this problem?
I am trying to create a field in SQL query builder that takes the input number 12345 and formats it 0000012345. In MSAccess there is a great Format() function which allowed this to be done easily, but I cant find an equivalent in SQLServer. Can anyone provide me with a new function and possibly a sample? Thanks in Advance,
I would like to add right number of 0 to make the data length of varchar (14) For example, before after 1768 -- > 0000001768.000 23456.78 --> 0000023456.780 123679.876 --> 0000123679.876
I have an SSIS routine which uses a simple SQL select statement from a SQL Server 2005 database and then goes to a Flat File destination. The field (dischstatuscode) is a nvarchar(50) and it may contain data with leading zeros.
Code Snippet Select DischStatusCode from dbo.pm
...which returns: 01 23 37 05 04 41
When I open up the csv file produced by the SSIS routine, I see the following: 1 23 37 5 4 41
I'm using DB2 Connect to access an IBM DB2 database, and I'm trying to import a table, having one VARCHAR field, containing multiple binary zeros, to SQL Server.
My problem is the VARCHAR type in SQL Server is defined as a null-terminated string of characters. So everytime I retrieve one of these values, it gets truncated (the first binary zero becames the end of the string).
I've tried using the TEXT data type, replacing the 0X00 character as part of the select , and using the native and .net OLE DB provider with no luck.
If anyone has faced the same problem before, I would appreciate any help.
Going against a Sybase database using ODBC, the numeric data in the amount field (money) drops all zero's to the right of a whole number when bringing it into MSQL 7. Example:
2,000.00 comes across as 2 2,001.00 comes across as 2,001.00
Has anyone a solution to this? What am I doing wrong? If I run a query against the SYBASE database, everything looks fine. Once I bring it into SQL, I'm about 9,000,000 dollars off.
I have an integer field that ranges from 3 to 6 numbers and I need to left pad leading zeros so the field is always a char(7). What is the syntax to do this? Thanks in advance.
I am creating a view which involved concatenation of 2 int columns.
The data in the columns look like
Column 1 Column 2 1234 1 12345 11
I am trying to get the following output
001234001 012345011
So the first column should have zeros padded to the front to make 6 numbers, the second column should be 3 numbers long with zeros in front. So when added together it is 9 numbers long.
What is the best way to change an output of P0123 to 123? i.e. drop the letter 'P' and also any leading zeros. We have a report that outputs terminal ID's which range from P0001 through to P0536.
I can drop the 'P' easily enough, but how I can drop the P000 from terminal ID P0001 for example.
I'm using varchar as a datatype and my leading zeros are chopped-off once ther data reaches my Stored Proc. The table will allow me to store the values with leading zeros if I enter them manually, but I cannot insert them via ASP/StoredProc.
Hi All, I need to set up a kind of identity insert that gives an output in the format: 00001, 00002, 00003 etc. Is there a formatting option for this sort of output using normal identity insert features or do I need to write a function to insert these values (perhaps as text) each time a new record is created? Sorry if this is really simple but it's only my 4th day in this job! Marcha
I am reposting this from the VB IDE forum, becaue I received no response
Using VS05 SP1 Pro/SQL Express...
There are two tables, UserIDs and Recordings (which has a foreign key relating it back to UserIDs).
I created a Stored Procedure via Server Explorer that returns the user ID for a given Foreign Key in Recordings table. If the UserID is "0001", then "0001" is return (userIDs are stored as strings). The stored procedure works every time.
I then created a table adpater that uses the above stored procedure. The table adapter is used in code. It has always worked fine, but i have discovered if the user ID starts with 0, those zeros are trimmed by the table adapter .
should result in a userID of "0001", but instead results in "1", which, from a string view point, is incorrect. As strings, "0001" and "1" are totally different, and the "1" fails when you do a fill for the table UserIDs.
So, the Stored Procedure and the Table Adapter using the same Stored Procedure return different results, with the Table Adapter being wrong. Why is it trimming the zeros? Is there anyway to stop that so the results are correct?
In my database I have "null" for some values of the data and now I want to change that to zero '0' due to some requirement. So, Is there any function for that?? So that all the "null"s in the database are changed to '0's......
I have a business rule in my environment where I need to insert right justified leading zeros in the column. For example if the value to be inserted is 12 than it should be inserted as 0000012. How can I do this
I'm uploading data from a CSV file into SQL Server 2000 using an upload routine in C# (ASP.NET 2.0). I'm using an OleDbDataAdapter to select all the data in the CSV file into a DataTable. I then use a SQLBulkCopy to copy all the data into my SQL Server table. The CSV file maps exactly to the fields in the SQL Server database and I've used a custom delimiter of a '~' (tilda) that is declared in a schema.ini file. The import works fine and my SQL Server table is fully populated with all the data. However, one source field in the CSV file is getting truncated in my SQL Server table. It is a field containing a value e.g. 32,000, 64,500 but this is getting truncated and losing the trailing zeros in SQL Server i.e. 32,000 (CSV) becomes 32 (SQL Server) and 64,500 becomes 65,5. I've tried mapping the source field to a varchar, nvarchar and text field, but all data types have the same problem with truncating the trailing zeros (I only need to display the data - no calculations required) and the ',' in the number in the CSV file has prevented me from mapping this to an integer. Also, locally the code works fine and my local database is SQL Server 2005, but the remote host is using SQL Server 2000 and this is where the problem occurs. Any help would be appreciated! Thanks
Good day gentleman, Is it possible to pad columns of Int data type with zeros?
I currently have a primary key column of data type Int which is auto-incremented by 1. My problem is I need to pad the auto-incremented ID's with ten zeros so, 0000000009 instead of 9.
I can pad the ID's in the c# dataaccess layer, but i need to generate/store them padded in the database to allow direct reporting.
I am using Enterprise Manager and i can see a Formula field when the table is in design view, can i use this? i am just guessing here.