Showing posts with label actual. Show all posts
Showing posts with label actual. Show all posts

Thursday, March 29, 2012

Edit .mdf database

Greetings,

Are there any tools freely available to modify or edit a .mdf database
file? As far as seeing the actual tables?

Regards,
cdMSDE:
http://www.microsoft.com/sql/msde/
http://www.aspfaq.com/show.asp?id=2442

--
David Portas
SQL Server MVP
--|||No, and I'm not sure why you'd want to do this - even if you managed to
change data pages in a .mdf file directly, you would corrupt the
metadata (indexes, allocation maps, statistics etc.), and the
transaction log would also need to be updated. As far as I know, MSSQL
itself is the only tool that can read and modify .mdf files (at least
outside Microsoft).

I'm not sure what your real goal is, but if you need to retrieve data
from an .mdf file, then you can try attaching it to an MSSQL
installation with sp_attach_single_file_db. If you don't have an MSSQL
installation, you can download MSDE for free, although it's limited to
2GB databases.

If this isn't helpful, I suggest you give some more details of what
you're trying to do.

Simon|||I pretty much want to be able to look at a .mdf file to see what could
be mangled in it. If for some reason the application that writes to
the database gives an error because of invalid character or something
in a certain field i would like to see what field it is and what's in
it. Simply attaching it does me no good.|||If you are developing an application then you could attach the DB to
Developer Edition (cost $50) to test for this sort of problem with the
benefit of Query Analyzer, Profiler and the other tools.

Is this scenario something you have actually experienced? What makes
you think that you could have a problem caused by an "invalid
character"?

If you think a database is corrupt then the DBCC command can be used to
validate a table or database and fix these problems.

--
David Portas
SQL Server MVP
--|||I don't really understand what sort of errors you're talking about. If
you can't insert data into a table, then MSSQL will return an error
message, which you need to handle in your client:

http://www.sommarskog.se/error-handling-I.html

Perhaps if you can give a more specific example of the sort of error
you're getting, someone can suggest a solution. It would also be good
to know which version of MSSQL you have, what client application or
library you're using, what query you're executing etc.

http://www.aspfaq.com/etiquette.asp?id=5006

Simon|||(mindphasr@.gmail.com) writes:
> I pretty much want to be able to look at a .mdf file to see what could
> be mangled in it.

If your database is corrupt so that you cannot easily repair it with
DBCC, you should open a case with Microsoft. Editing the internal
structures of database file will just mangle it even more.

> If for some reason the application that writes to the database gives an
> error because of invalid character or something in a certain field i
> would like to see what field it is and what's in it. Simply attaching it
> does me no good.

Your application cannot on its own corrupt the database. It would
need help from either a bug in SQL Server or bad hardware.

If your application produces an error message, you should first use the
Profiler to find where what statements the application is sending. Once
there you can run the queries in Query Analyzer. In QA you can run commands
like sp_help to see the definition of tables and constraints etc.

My guess is that you run a third-party app. In such, you should open a
support case with that vendor.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Easy way to index a column with URLs

We have a column that stores URL (varchar), which ultimately are unique
within the table (though an identity is the actual primary key). Is it good
practice to put an index on such a wide column? Are there are other
alternatives, possibly different data type to use?If you need to enforce uniqueness, or you are frequently searching the table
by the URL column, then an index is appropriate. Bear in mind that an index
key can be no more than 900 bytes.
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Kevin" <none@.none.com> wrote in message
news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
We have a column that stores URL (varchar), which ultimately are unique
within the table (though an identity is the actual primary key). Is it good
practice to put an index on such a wide column? Are there are other
alternatives, possibly different data type to use?|||I'm afraid that some of the urls possibly could get over that size after
encoding (the URL column is nvarchar).
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
> If you need to enforce uniqueness, or you are frequently searching the
> table
> by the URL column, then an index is appropriate. Bear in mind that an
> index
> key can be no more than 900 bytes.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Kevin" <none@.none.com> wrote in message
> news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
> We have a column that stores URL (varchar), which ultimately are unique
> within the table (though an identity is the actual primary key). Is it
> good
> practice to put an index on such a wide column? Are there are other
> alternatives, possibly different data type to use?
>|||"Kevin" <none@.none.com> wrote in message
news:0DCDCCBA-8397-46D2-A860-8432E352277B@.microsoft.com...
> I'm afraid that some of the urls possibly could get over that size after
> encoding (the URL column is nvarchar).
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
>> If you need to enforce uniqueness, or you are frequently searching the
>> table
>> by the URL column, then an index is appropriate. Bear in mind that an
>> index
>> key can be no more than 900 bytes.
>> --
>> Tom
>> ----
>> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
>> SQL Server MVP
>> Toronto, ON Canada
>> https://mvp.support.microsoft.com/profile/Tom.Moreau
>>
>> "Kevin" <none@.none.com> wrote in message
>> news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
>> We have a column that stores URL (varchar), which ultimately are unique
>> within the table (though an identity is the actual primary key). Is it
>> good
>> practice to put an index on such a wide column? Are there are other
>> alternatives, possibly different data type to use?
>|||Kevin,
if you badly want this column be indexed (of those values that do not excede
the 900 bites limit), you can do some more work:
create an indexed view that have a pk column and the URL column, with the
URL records no longer than 900 bites, index on the URL column;
create an indexed view that have a pk column and the URL column, with the
URL records longer than 900 bites, index on the pk column;
chances are that you may have a handful of records in the second view so
that you do not care to index scan it. And you have index seek on the
shorter URL values. Then join the views with your base table.
HTH
Quentin
"Kevin" <none@.none.com> wrote in message
news:0DCDCCBA-8397-46D2-A860-8432E352277B@.microsoft.com...
> I'm afraid that some of the urls possibly could get over that size after
> encoding (the URL column is nvarchar).
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
>> If you need to enforce uniqueness, or you are frequently searching the
>> table
>> by the URL column, then an index is appropriate. Bear in mind that an
>> index
>> key can be no more than 900 bytes.
>> --
>> Tom
>> ----
>> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
>> SQL Server MVP
>> Toronto, ON Canada
>> https://mvp.support.microsoft.com/profile/Tom.Moreau
>>
>> "Kevin" <none@.none.com> wrote in message
>> news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
>> We have a column that stores URL (varchar), which ultimately are unique
>> within the table (though an identity is the actual primary key). Is it
>> good
>> practice to put an index on such a wide column? Are there are other
>> alternatives, possibly different data type to use?
>sql

Easy way to index a column with URLs

We have a column that stores URL (varchar), which ultimately are unique
within the table (though an identity is the actual primary key). Is it good
practice to put an index on such a wide column? Are there are other
alternatives, possibly different data type to use?
If you need to enforce uniqueness, or you are frequently searching the table
by the URL column, then an index is appropriate. Bear in mind that an index
key can be no more than 900 bytes.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Kevin" <none@.none.com> wrote in message
news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
We have a column that stores URL (varchar), which ultimately are unique
within the table (though an identity is the actual primary key). Is it good
practice to put an index on such a wide column? Are there are other
alternatives, possibly different data type to use?
|||I'm afraid that some of the urls possibly could get over that size after
encoding (the URL column is nvarchar).
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
> If you need to enforce uniqueness, or you are frequently searching the
> table
> by the URL column, then an index is appropriate. Bear in mind that an
> index
> key can be no more than 900 bytes.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Kevin" <none@.none.com> wrote in message
> news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
> We have a column that stores URL (varchar), which ultimately are unique
> within the table (though an identity is the actual primary key). Is it
> good
> practice to put an index on such a wide column? Are there are other
> alternatives, possibly different data type to use?
>
|||"Kevin" <none@.none.com> wrote in message
news:0DCDCCBA-8397-46D2-A860-8432E352277B@.microsoft.com...
> I'm afraid that some of the urls possibly could get over that size after
> encoding (the URL column is nvarchar).
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
>
|||Kevin,
if you badly want this column be indexed (of those values that do not excede
the 900 bites limit), you can do some more work:
create an indexed view that have a pk column and the URL column, with the
URL records no longer than 900 bites, index on the URL column;
create an indexed view that have a pk column and the URL column, with the
URL records longer than 900 bites, index on the pk column;
chances are that you may have a handful of records in the second view so
that you do not care to index scan it. And you have index seek on the
shorter URL values. Then join the views with your base table.
HTH
Quentin
"Kevin" <none@.none.com> wrote in message
news:0DCDCCBA-8397-46D2-A860-8432E352277B@.microsoft.com...
> I'm afraid that some of the urls possibly could get over that size after
> encoding (the URL column is nvarchar).
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
>

Easy way to index a column with URLs

We have a column that stores URL (varchar), which ultimately are unique
within the table (though an identity is the actual primary key). Is it good
practice to put an index on such a wide column? Are there are other
alternatives, possibly different data type to use?If you need to enforce uniqueness, or you are frequently searching the table
by the URL column, then an index is appropriate. Bear in mind that an index
key can be no more than 900 bytes.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Kevin" <none@.none.com> wrote in message
news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
We have a column that stores URL (varchar), which ultimately are unique
within the table (though an identity is the actual primary key). Is it good
practice to put an index on such a wide column? Are there are other
alternatives, possibly different data type to use?|||I'm afraid that some of the urls possibly could get over that size after
encoding (the URL column is nvarchar).
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
> If you need to enforce uniqueness, or you are frequently searching the
> table
> by the URL column, then an index is appropriate. Bear in mind that an
> index
> key can be no more than 900 bytes.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Kevin" <none@.none.com> wrote in message
> news:4671898C-0CAC-4396-85F1-BA45E527D8E5@.microsoft.com...
> We have a column that stores URL (varchar), which ultimately are unique
> within the table (though an identity is the actual primary key). Is it
> good
> practice to put an index on such a wide column? Are there are other
> alternatives, possibly different data type to use?
>|||"Kevin" <none@.none.com> wrote in message
news:0DCDCCBA-8397-46D2-A860-8432E352277B@.microsoft.com...
> I'm afraid that some of the urls possibly could get over that size after
> encoding (the URL column is nvarchar).
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
>|||Kevin,
if you badly want this column be indexed (of those values that do not excede
the 900 bites limit), you can do some more work:
create an indexed view that have a pk column and the URL column, with the
URL records no longer than 900 bites, index on the URL column;
create an indexed view that have a pk column and the URL column, with the
URL records longer than 900 bites, index on the pk column;
chances are that you may have a handful of records in the second view so
that you do not care to index scan it. And you have index seek on the
shorter URL values. Then join the views with your base table.
HTH
Quentin
"Kevin" <none@.none.com> wrote in message
news:0DCDCCBA-8397-46D2-A860-8432E352277B@.microsoft.com...
> I'm afraid that some of the urls possibly could get over that size after
> encoding (the URL column is nvarchar).
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:O0MdobtnHHA.1476@.TK2MSFTNGP03.phx.gbl...
>

Friday, February 17, 2012

Dynamic Sql Parse - Please help!

okay I have found the table name that I want dropped using the dynamic sql
below. I'm not quite sure how to populate @.TableToDrop for the actual drop
statement though. Can you help? I hope the indentation is not too bad and yo
u
can read the Statement ok
Set @.lnvchCommand = ' IF EXISTS ' +
' ( SELECT *
FROM WH_BKUPS..SYSOBJECTS
WHERE NAME like ' + '''' + @.lvchTable_Name + '_%' + '''' + '
AND NAME < ' + '''' + @.lvchTable_Name + '_' + @.exc_date_id + '''' +
' ) ' +
' Select @.lchTable_Exists = ''Y''' +
' Else ' +
Select @.lchTable_Exists = ''N'''
Execute sp_executesql @.lnvchCommand, @.ParmDefinition, @.lchTable_Exists OUTPU
T
If @.lchTable_Exists = 'Y'
Begin
DROP TABLE @.TableToDrop
EndUse dynamic SQL for the drop, for instance:
If @.lchTable_Exists = 'Y'
Begin
EXEC('DROP TABLE ' + @.TableToDrop)
End
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"marcmc" <marcmc@.discussions.microsoft.com> wrote in message
news:4131048F-69B2-4765-88DB-E940E0E1B4AB@.microsoft.com...
> okay I have found the table name that I want dropped using the dynamic sql
> below. I'm not quite sure how to populate @.TableToDrop for the actual drop
> statement though. Can you help? I hope the indentation is not too bad and
you
> can read the Statement ok
> Set @.lnvchCommand = ' IF EXISTS ' +
> ' ( SELECT *
> FROM WH_BKUPS..SYSOBJECTS
> WHERE NAME like ' + '''' + @.lvchTable_Name + '_%' + '''' + '
> AND NAME < ' + '''' + @.lvchTable_Name + '_' + @.exc_date_id + '''' +
> ' ) ' +
> ' Select @.lchTable_Exists = ''Y''' +
> ' Else ' +
> Select @.lchTable_Exists = ''N'''
> Execute sp_executesql @.lnvchCommand, @.ParmDefinition, @.lchTable_Exists OUT
PUT
> If @.lchTable_Exists = 'Y'
> Begin
> DROP TABLE @.TableToDrop
> End
>|||You'll have to assign the table name to a variable and use EXEC or
sp_executesql for the DROP statement as well.
Why don't you know what tables exist in your database? This might be a
reasonable thing to do in an ad-hoc admin script (not really sure why
though) but in a business process application your table structures
ought to be static at runtime so this should never be necessary.
David Portas
SQL Server MVP
--|||thanks guys for your help. Much appreciated but I have found a solution.
what I would love how to do though is drop a table as follows
declare @.TableToDrop char(50)
select @.TableToDrop = 'marc'
print @.TableToDrop
drop table DBName..+@.TableToDrop
tearing my hair out...|||declare @.TableToDrop char(50)
select @.TableToDrop = 'marc'
print @.TableToDrop
EXEC('drop table DBName..' + @.TableToDrop)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"marcmc" <marcmc@.discussions.microsoft.com> wrote in message
news:CF46E496-BD1C-47A0-9053-CFFADC337609@.microsoft.com...
> thanks guys for your help. Much appreciated but I have found a solution.
> what I would love how to do though is drop a table as follows
> declare @.TableToDrop char(50)
> select @.TableToDrop = 'marc'
> print @.TableToDrop
> drop table DBName..+@.TableToDrop
> tearing my hair out...|||> what I would love how to do though is drop a table as follows

> declare @.TableToDrop char(50)
> select @.TableToDrop = 'marc'
> print @.TableToDrop
> drop table DBName..+@.TableToDrop
This isn't supported because the basic concept for database
applications is that tables are created at design time and do not
change at runtime. In other words you should know what your table names
are and not need to parameterize them. That's why I asked why you need
to do this.
David Portas
SQL Server MVP
--|||Perhaps I should add that I fully agree with David, you should know the name
s of the tables and
there should be no need to, from an application, keep dropping tables. This
is most often a sign of
a mistake in the data modeling.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message
news:eVD8i2aRFHA.2976@.TK2MSFTNGP10.phx.gbl...
> declare @.TableToDrop char(50)
> select @.TableToDrop = 'marc'
> print @.TableToDrop
> EXEC('drop table DBName..' + @.TableToDrop)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "marcmc" <marcmc@.discussions.microsoft.com> wrote in message
> news:CF46E496-BD1C-47A0-9053-CFFADC337609@.microsoft.com...
>|||This is not an RDBMS but a 1950's mag tape file system in a realllllly
bad disguise. The IBM convention for tape labels was "yyddd" , just
like you are using almost 60 years later!
SQL programmers have a schema that models the entities in their reality
in tables. Dropping and creating tables on the fly is an insanely poor
practice. It leads to dynamic SQL and other kludges. It says that
your model is in constant flux, never quite dependable. It says that
you live in a Phillip K. Dick world.
Get your boss to pay for some basic data modeling classes.