Accidentally created new LDF, now get error with old LDF

Greetings all. I wanted to separate the MDF and LDF files. I am an SQL
newbie and here is what I did.
1. Detach MDF through right-click options
2. Move LDF to new drive
3. Attach MDF through right-click options
4. Path would not change for original LDF location and I hit OK by
accident (not sure how) but I did, and it created a new LDF in the
original location.
5. Detach MDF again
6. Attach MDF again
7. Manually typed path of moved LDF (the one I wanted to begin with)
and did not click verify (that always changed the location back to the
original). Just clicked OK and it took the path.
8. ERROR 5173 Cannot associate files with different databases
Any help would be greatly appreciated.
Regards,
GaryWhen you attached the db the first time it created a new log file and
adjusted the metadata to account for it. At that point the original log
file was no longer valid. So you should detach it and move the new log file
to the other location and attach that one.
--
Andrew J. Kelly SQL MVP
"Dreamer" <spencermountains@.yahoo.com> wrote in message
news:1134830448.181128.92340@.z14g2000cwz.googlegroups.com...
> Greetings all. I wanted to separate the MDF and LDF files. I am an SQL
> newbie and here is what I did.
> 1. Detach MDF through right-click options
> 2. Move LDF to new drive
> 3. Attach MDF through right-click options
> 4. Path would not change for original LDF location and I hit OK by
> accident (not sure how) but I did, and it created a new LDF in the
> original location.
> 5. Detach MDF again
> 6. Attach MDF again
> 7. Manually typed path of moved LDF (the one I wanted to begin with)
> and did not click verify (that always changed the location back to the
> original). Just clicked OK and it took the path.
> 8. ERROR 5173 Cannot associate files with different databases
> Any help would be greatly appreciated.
> Regards,
> Gary
>|||Thanks for the reply. Do I not need the original LDF file then? Have I
lost anything?|||Hopefully not<g>. When you detach the db it should commit or rollback all
transactions that haven't already been attended to. Before you do anything
like detach a db it is always a good idea to do a full backup first in case
anything happens and you need to get back to where you were. But in this
case you should be fine as long as the attach works with no errors.
--
Andrew J. Kelly SQL MVP
"Dreamer" <spencermountains@.yahoo.com> wrote in message
news:1134832357.374087.105070@.g44g2000cwa.googlegroups.com...
> Thanks for the reply. Do I not need the original LDF file then? Have I
> lost anything?
>

Access-like Automation in SQL Server 2005?

I'm a newbie to SQL Server, trying to make the leap from Access because I'm starting out grow it for my needs. I have a lot of automation stuff in Access where it does a query/code driven process for us via a macro. Sometimes the output is a report, or a form with assembled data that we use. I'm wondering if SQL Server 2005 is capable of doing automation of processes like these as well. Even if it's not necessarily a macro, something I can program, compile and have use off of my SQL Server database to do the tasks that the Access macro did.This is one of those sticky kinds of questions...

SQL Server has lots of tools/toys. You can automate all of them, with varying degrees of effort. It depends on what tools you are using, and what results you want to achieve.

You can actually use SQL Server in place of Jet and continue using Microsoft Access. Jet is the default database engine provided with Microsoft Access, but the Microsoft Access GUI can actually use any ODBC database engine.

Micrsoft Access presents a "one stop shop" with environment, data engine, etc all in one package. Microsoft SQL Server provides more powerful data storage/management/manipulation tools, but little or nothing in the way of "front end" tools. SQL Server is much better for the "heavy lifting" of your data, but it really doesn't provide anything in the way of a user interface.

-PatP