Locked Stored Procedures

Hi

I am reasonably new to this so bear with me.

I have a copy of a SQL Server 2000 Database, and would like to see what the stored procedures are doing (as I think it is wrong).

in Server Management Studio the stored procedures have a lock symbol on them and when I try and view them I get the message:

TITLE: Microsoft SQL Server Management Studio

Script failed for StoredProcedure 'dbo.sp_procedure'. (Microsoft.SqlServer.Smo)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.1399.00&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Script+StoredProcedure&LinkId=20476

ADDITIONAL INFORMATION:

Property TextHeader is not available for StoredProcedure '[dbo].[sp_procedureprocedure]'. This property may not exist for this object, or may not be retrievable due to insufficient access rights. The text is encrypted. (Microsoft.SqlServer.Smo)

This was developed by someone else, but I need to see it.

My question is, is there any way i can see the text of this stored procedure?

Thanks

Will

The stored procedure code has been encrypted. Apparently, whoever wrote the code didn't want others to read the code.

I suggest that you contact the person ( or vendor ) that supplied the stored procedure code and request a copy of the code.

Location of reports?

I cannot find the original copy of a report that is uploaded onto my Report
Server. Where does Reporting Services store the uploaded reports? I need a
physical location so I may copy the .rdl file and edit it.
Is there any other way to copy the report file from inside Reporting
Services?it is in the directory of the report project if you are using VS.NET.
another alternative for the rdl is to select the report properties and
'Update' it (specifying the location of the .rdl - which is what we do for
production here).
Also, you may upload from RM basically anything (it doesn't have to be an
RDL). Let's say for instance that the folder for a department needs a monthly
.XLS for all to work from...
r
"Amon Borland" wrote:
> I cannot find the original copy of a report that is uploaded onto my Report
> Server. Where does Reporting Services store the uploaded reports? I need a
> physical location so I may copy the .rdl file and edit it.
> Is there any other way to copy the report file from inside Reporting
> Services?
>
>|||I was not as complete as I should have been with my answer from post.
if in doubt, look in the ReportServer database (if you used the default name
fom the install) and open the Catalog table. the name and path for the report
are located there.
r
"tutor" wrote:
> it is in the directory of the report project if you are using VS.NET.
> another alternative for the rdl is to select the report properties and
> 'Update' it (specifying the location of the .rdl - which is what we do for
> production here).
> Also, you may upload from RM basically anything (it doesn't have to be an
> RDL). Let's say for instance that the folder for a department needs a monthly
> .XLS for all to work from...
> r
> "Amon Borland" wrote:
> > I cannot find the original copy of a report that is uploaded onto my Report
> > Server. Where does Reporting Services store the uploaded reports? I need a
> > physical location so I may copy the .rdl file and edit it.
> >
> > Is there any other way to copy the report file from inside Reporting
> > Services?
> >
> >
> >|||Amon, the report is stored by RS in the database. It does not exist as a
file. You can use Report Manager to retrieve it (properties of report,
edit).
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"tutor" <tutor@.discussions.microsoft.com> wrote in message
news:A431F911-100A-4FCE-852E-D7E2E5CC523E@.microsoft.com...
>I was not as complete as I should have been with my answer from post.
> if in doubt, look in the ReportServer database (if you used the default
> name
> fom the install) and open the Catalog table. the name and path for the
> report
> are located there.
> r
> "tutor" wrote:
>> it is in the directory of the report project if you are using VS.NET.
>> another alternative for the rdl is to select the report properties and
>> 'Update' it (specifying the location of the .rdl - which is what we do
>> for
>> production here).
>> Also, you may upload from RM basically anything (it doesn't have to be an
>> RDL). Let's say for instance that the folder for a department needs a
>> monthly
>> .XLS for all to work from...
>> r
>> "Amon Borland" wrote:
>> > I cannot find the original copy of a report that is uploaded onto my
>> > Report
>> > Server. Where does Reporting Services store the uploaded reports? I
>> > need a
>> > physical location so I may copy the .rdl file and edit it.
>> >
>> > Is there any other way to copy the report file from inside Reporting
>> > Services?
>> >
>> >
>> >sql

locate static data in xml file vs db table

How do people see the security of locating static data (such as config
settings) in an XML file (a copy is located on each web-server, or a single
copy is located on a specific server) , versus locating this data inside the
db ?
An XML file that contains all app config settings is much easier to maintain
and track from the standpoint of source-code-control , and it is much easier
to apply changes to settings in production environments (just swap the XML
file and restart the web-servers).
The replication and other redudancy advantages accorded data inside SS are
not really necessary for static, load-on-app-start, config settings.
If not possible for data in an XML file to achieve the security of a data in
a db , one option would be to locate the XML file in a SS05 col of XML
datatype.
Anyone have real-world experience making this sort of trade-off decision ,
or any insights ?
Thanks.When did go through a similar exercise for our application. One of the
things that we considered was to look at configuration as something that is
"configurable". This means that the location of the configuration file
should be abstracted from your code so that you are free to move it around.
This is where the Configuration Application Block from Microsoft comes into
play:
http://msdn.microsoft.com/library/d...i
g.asp.
This block abstracts the ability to read and write from the configuration
file and from a deployment perspective, the configuration can be in XML or
in SQL Server. Maybe future editions of this block might put it in an SQL2K5
XML column, but the block would abstract it from you and you would always
have a consistent way of programming.
--
HTH,
SriSamp
Email: srisamp@.gmail.com
Blog: http://blogs.sqlxml.org/srinivassampath
URL: http://www32.brinkster.com/srisamp
"John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
news:OnfTXLs0FHA.3812@.TK2MSFTNGP09.phx.gbl...
> How do people see the security of locating static data (such as config
> settings) in an XML file (a copy is located on each web-server, or a
> single copy is located on a specific server) , versus locating this data
> inside the db ?
> An XML file that contains all app config settings is much easier to
> maintain and track from the standpoint of source-code-control , and it is
> much easier to apply changes to settings in production environments (just
> swap the XML file and restart the web-servers).
> The replication and other redudancy advantages accorded data inside SS are
> not really necessary for static, load-on-app-start, config settings.
> If not possible for data in an XML file to achieve the security of a data
> in a db , one option would be to locate the XML file in a SS05 col of XML
> datatype.
> Anyone have real-world experience making this sort of trade-off decision ,
> or any insights ?
> Thanks.
>|||Problem I see with Configuration Application Block is that it assumes only
the simplest data structure is needed for config settings: discrete named
values.
To get around this, you can write your own transformers. But to leverage the
advantages that CAB offers, you should write them to work against multiple
data-providers/data-stores). This is quite a bit of work -- might be better
to spend that time writing an app-specific solution from scratch.
Also, I think it's not a good idea to avoid upfront analysis of the
app-specific trade-offs between different data-store solutions. CAB seems to
be saying "avoid the tough design decision" ... and, in the process,
sacrifice the advantages offered by a custom design.
But maybe I'm mistaken ...
"SriSamp" <ssampath@.sct.co.in> wrote in message
news:O4Ervev0FHA.460@.TK2MSFTNGP15.phx.gbl...
> When did go through a similar exercise for our application. One of the
> things that we considered was to look at configuration as something that
> is "configurable". This means that the location of the configuration file
> should be abstracted from your code so that you are free to move it
> around. This is where the Configuration Application Block from Microsoft
> comes into play:
> http://msdn.microsoft.com/library/d...br />
fig.asp.
> This block abstracts the ability to read and write from the configuration
> file and from a deployment perspective, the configuration can be in XML or
> in SQL Server. Maybe future editions of this block might put it in an
> SQL2K5 XML column, but the block would abstract it from you and you would
> always have a consistent way of programming.
> --
> HTH,
> SriSamp
> Email: srisamp@.gmail.com
> Blog: http://blogs.sqlxml.org/srinivassampath
> URL: http://www32.brinkster.com/srisamp
> "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
> news:OnfTXLs0FHA.3812@.TK2MSFTNGP09.phx.gbl...
>|||You're right in saying that CAB out of the box is for simple named values.
We have not tried writing our own formatters, thus, I cannot comment on the
complexity of the same. We did do an anslysis of an application specific
version, but found that the time it takes to provide a UI for the
configuration (like what CAB has) and the simple model of exposing the
configuration as properties of a class for our application looked like a
re-invention of the wheel.
Did you try posting your question to the GOTDOTNET site for Enterprise
Library? It is usually manned by the architects of the library and you may
get more specific answers.
--
HTH,
SriSamp
Email: srisamp@.gmail.com
Blog: http://blogs.sqlxml.org/srinivassampath
URL: http://www32.brinkster.com/srisamp
"John Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
news:O71N%23oz0FHA.2132@.TK2MSFTNGP15.phx.gbl...
> Problem I see with Configuration Application Block is that it assumes only
> the simplest data structure is needed for config settings: discrete named
> values.
> To get around this, you can write your own transformers. But to leverage
> the advantages that CAB offers, you should write them to work against
> multiple data-providers/data-stores). This is quite a bit of work --
> might be better to spend that time writing an app-specific solution from
> scratch.
> Also, I think it's not a good idea to avoid upfront analysis of the
> app-specific trade-offs between different data-store solutions. CAB seems
> to be saying "avoid the tough design decision" ... and, in the process,
> sacrifice the advantages offered by a custom design.
> But maybe I'm mistaken ...
> "SriSamp" <ssampath@.sct.co.in> wrote in message
> news:O4Ervev0FHA.460@.TK2MSFTNGP15.phx.gbl...
>

Local Reporting Services and Remote SQL Server

I am new to Reporting Services, so this may be a simple question. I want to try and download the evaluation copy of Microsoft's RS from their website, however, they require you to have a SQL Server db setup. I have one, but it is remote. I do all my development in Visual Studio on Server A and have my db setup on Server B. I want to be able to use RS within Visual Studio, so I am assuming I need to install RS on Server A. Or do I need to just install on Server B with the database (or both)?

Thanks for your help...

MS SQL Reporting Services is just an ASP.NET web application. You can install it on IIS servers that have .NET 1.1. You do not have to install it on the DB server. The MS SQL reporting services application stores its catalog in the db and thus you need to have a SQL server when installing it. The MS SQL reporting services installation has two components: the server component (to be installed on the web server) and the developer component (to be installed on developer workstation that has the Visual Studio). Using Visual Studio, you can build reports and then publish tem to the web server where you installed the MS SQL Reporting Services server component. In your case, you can install both components on Server A.

Hope this helps

Local DB Affected By VPN

I work on a local copy of a database (Access 2000 MDB with ODBC linked
tables to a SQL 7 database). The SQL Server db I'm working with is on my C
drive (MSDE). Occasionally I'll connect to a VPN to do something on a remote
computer, using PC Anywhere to perform the task. Doesn't involve my front or
back end at all, except that the computer I'm VPNing to has a SQL database
running.
OK, so I'm using my db; I connect to the VPN, and do my thing. Everything's
fine. However, if I then disconnect from the VPN (or if the VPN connection
times out and disconnects itself), I then can no longer access my local SQL
Server database. My Access application still works fine, as long as it
doesn't have to look at any data. When it does have to look at data, I get
ODBC call failed. I have to close and reopen my Access database, and then
everything is fine.
So, it seems that, for some reason, when I connect to the VPN, my local SQL
Server or the ODBC driver or something in the mix is looking at that remote
database as part of what I'm using. Then, when the VPN connection is closed,
it won't access my local database for some reason.
Oh, and my local database and the remote database both have the same name.
So that may be part of the problem.
Any ideas as to what's going on?
Thanks!
Neil
On 26 Nov, 10:15, "Neil" <nos...@.nospam.net> wrote:
> I work on a local copy of a database (Access 2000 MDB with ODBC linked
> tables to a SQL 7 database). The SQL Server db I'm working with is on my C
> drive (MSDE). Occasionally I'll connect to a VPN to do something on a remote
> computer, using PC Anywhere to perform the task. Doesn't involve my front or
> back end at all, except that the computer I'm VPNing to has a SQL database
> running.
> OK, so I'm using my db; I connect to the VPN, and do my thing. Everything's
> fine. However, if I then disconnect from the VPN (or if the VPN connection
> times out and disconnects itself), I then can no longer access my local SQL
> Server database. My Access application still works fine, as long as it
> doesn't have to look at any data. When it does have to look at data, I get
> ODBC call failed. I have to close and reopen my Access database, and then
> everything is fine.
> So, it seems that, for some reason, when I connect to the VPN, my local SQL
> Server or the ODBC driver or something in the mix is looking at that remote
> database as part of what I'm using. Then, when the VPN connection is closed,
> it won't access my local database for some reason.
> Oh, and my local database and the remote database both have the same name.
> So that may be part of the problem.
> Any ideas as to what's going on?
> Thanks!
> Neil
It's only a guess but have you got the means of using Remote Desktop
Terminal Services Client or MSN Messenger Remote Assistance (As a
test) instead of PCAnywhere? I worked on the Laplink support line many
years ago and can imagine that this might be the issue and rings some
bells but things have changed since.
All the best,
Martin
|||On 27 Nov, 13:46, theintrepidfox <theintrepid...@.hotmail.com> wrote:
> On 26 Nov, 10:15, "Neil" <nos...@.nospam.net> wrote:
>
>
>
>
>
>
> It's only a guess but have you got the means of using Remote Desktop
> Terminal Services Client or MSN Messenger Remote Assistance (As a
> test) instead of PCAnywhere? I worked on the Laplink support line many
> years ago and can imagine that this might be the issue and rings some
> bells but things have changed since.
> All the best,
> Martin- Hide quoted text -
> - Show quoted text -
The reason why I'm suggestin it is because PCAnywhere is perhaps
trying to synchromize files between the client and host (including
your .mdb) which is maybe still and remains in use by the Sync Process
when the VPN times out or disconnects.
|||Actually, it usually happens after PCAnywhere has been closed. While
PCAnywhere is open, the VPN connection stays active. After I close
PCAnywhere, if I don't disconnect from the VPN, then eventually the VPN
connection times out.
So, a typical scenario is: open Access app connected to local SQL Server;
later, connect to VPN and do stuff via PCAnywhere; close PCAnywhere; later,
VPN connection disconnects, and then connection to local SQL Server fails.
Have to close and reopen MDB for it to work.
Strange...
"theintrepidfox" <theintrepidfox@.hotmail.com> wrote in message
news:3e278590-302d-4549-82d4-2e12c0b51b1a@.i29g2000prf.googlegroups.com...
> On 26 Nov, 10:15, "Neil" <nos...@.nospam.net> wrote:
> It's only a guess but have you got the means of using Remote Desktop
> Terminal Services Client or MSN Messenger Remote Assistance (As a
> test) instead of PCAnywhere? I worked on the Laplink support line many
> years ago and can imagine that this might be the issue and rings some
> bells but things have changed since.
> All the best,
> Martin
|||"theintrepidfox" <theintrepidfox@.hotmail.com> wrote in message
news:9cb60b5b-5160-4afe-8555-8ed2bed12b09@.s36g2000prg.googlegroups.com...
> On 27 Nov, 13:46, theintrepidfox <theintrepid...@.hotmail.com> wrote:
> The reason why I'm suggestin it is because PCAnywhere is perhaps
> trying to synchromize files between the client and host (including
> your .mdb) which is maybe still and remains in use by the Sync Process
> when the VPN times out or disconnects.
Yeah, I don't think that's it. I tried connecting to the VPN without doing
anything else, and the results were the same. Something in SQL Server itself
is looking at that other server for some reason. Maybe because they both
have same-named databases. I don't know.
Thanks,
Neil
|||Not really, but you may try adding an entry to your host file pointing to
your local box and using the loopback IP. My vague guess is that possibly
you're getting into a situation where you get an IP through VPN and it
doesn't resolve the new IP when you get disconnected. Mind you, that's just
a guess, but it's all I've got right now.
Anyway, try the host file thing and see if that does anything for you.
"Neil" wrote:

> I work on a local copy of a database (Access 2000 MDB with ODBC linked
> tables to a SQL 7 database). The SQL Server db I'm working with is on my C
> drive (MSDE). Occasionally I'll connect to a VPN to do something on a remote
> computer, using PC Anywhere to perform the task. Doesn't involve my front or
> back end at all, except that the computer I'm VPNing to has a SQL database
> running.
> OK, so I'm using my db; I connect to the VPN, and do my thing. Everything's
> fine. However, if I then disconnect from the VPN (or if the VPN connection
> times out and disconnects itself), I then can no longer access my local SQL
> Server database. My Access application still works fine, as long as it
> doesn't have to look at any data. When it does have to look at data, I get
> ODBC call failed. I have to close and reopen my Access database, and then
> everything is fine.
> So, it seems that, for some reason, when I connect to the VPN, my local SQL
> Server or the ODBC driver or something in the mix is looking at that remote
> database as part of what I'm using. Then, when the VPN connection is closed,
> it won't access my local database for some reason.
> Oh, and my local database and the remote database both have the same name.
> So that may be part of the problem.
> Any ideas as to what's going on?
> Thanks!
> Neil
>
>

Local DB Affected By VPN

I work on a local copy of a database (Access 2000 MDB with ODBC linked
tables to a SQL 7 database). The SQL Server db I'm working with is on my C
drive (MSDE). Occasionally I'll connect to a VPN to do something on a remote
computer, using PC Anywhere to perform the task. Doesn't involve my front or
back end at all, except that the computer I'm VPNing to has a SQL database
running.

OK, so I'm using my db; I connect to the VPN, and do my thing. Everything's
fine. However, if I then disconnect from the VPN (or if the VPN connection
times out and disconnects itself), I then can no longer access my local SQL
Server database. My Access application still works fine, as long as it
doesn't have to look at any data. When it does have to look at data, I get
ODBC call failed. I have to close and reopen my Access database, and then
everything is fine.

So, it seems that, for some reason, when I connect to the VPN, my local SQL
Server or the ODBC driver or something in the mix is looking at that remote
database as part of what I'm using. Then, when the VPN connection is closed,
it won't access my local database for some reason.

Oh, and my local database and the remote database both have the same name.
So that may be part of the problem.

Any ideas as to what's going on?

Thanks!

NeilOn 26 Nov, 10:15, "Neil" <nos...@.nospam.netwrote:

Quote:

Originally Posted by

I work on a local copy of a database (Access 2000 MDB with ODBC linked
tables to a SQL 7 database). The SQL Server db I'm working with is on my C
drive (MSDE). Occasionally I'll connect to a VPN to do something on a remote
computer, using PC Anywhere to perform the task. Doesn't involve my front or
back end at all, except that the computer I'm VPNing to has a SQL database
running.
>
OK, so I'm using my db; I connect to the VPN, and do my thing. Everything's
fine. However, if I then disconnect from the VPN (or if the VPN connection
times out and disconnects itself), I then can no longer access my local SQL
Server database. My Access application still works fine, as long as it
doesn't have to look at any data. When it does have to look at data, I get
ODBC call failed. I have to close and reopen my Access database, and then
everything is fine.
>
So, it seems that, for some reason, when I connect to the VPN, my local SQL
Server or the ODBC driver or something in the mix is looking at that remote
database as part of what I'm using. Then, when the VPN connection is closed,
it won't access my local database for some reason.
>
Oh, and my local database and the remote database both have the same name.
So that may be part of the problem.
>
Any ideas as to what's going on?
>
Thanks!
>
Neil

It's only a guess but have you got the means of using Remote Desktop
Terminal Services Client or MSN Messenger Remote Assistance (As a
test) instead of PCAnywhere? I worked on the Laplink support line many
years ago and can imagine that this might be the issue and rings some
bells but things have changed since.

All the best,

Martin|||On 27 Nov, 13:46, theintrepidfox <theintrepid...@.hotmail.comwrote:

Quote:

Originally Posted by

On 26 Nov, 10:15, "Neil" <nos...@.nospam.netwrote:
>
>
>
>
>

Quote:

Originally Posted by

I work on a local copy of a database (Access 2000 MDB with ODBC linked
tables to a SQL 7 database). The SQL Server db I'm working with is on my C
drive (MSDE). Occasionally I'll connect to a VPN to do something on a remote
computer, using PC Anywhere to perform the task. Doesn't involve my front or
back end at all, except that the computer I'm VPNing to has a SQL database
running.

>

Quote:

Originally Posted by

OK, so I'm using my db; I connect to the VPN, and do my thing. Everything's
fine. However, if I then disconnect from the VPN (or if the VPN connection
times out and disconnects itself), I then can no longer access my local SQL
Server database. My Access application still works fine, as long as it
doesn't have to look at any data. When it does have to look at data, I get
ODBC call failed. I have to close and reopen my Access database, and then
everything is fine.

>

Quote:

Originally Posted by

So, it seems that, for some reason, when I connect to the VPN, my local SQL
Server or the ODBC driver or something in the mix is looking at that remote
database as part of what I'm using. Then, when the VPN connection is closed,
it won't access my local database for some reason.

>

Quote:

Originally Posted by

Oh, and my local database and the remote database both have the same name.
So that may be part of the problem.

>

Quote:

Originally Posted by

Any ideas as to what's going on?

>

Quote:

Originally Posted by

Thanks!

>

Quote:

Originally Posted by

Neil

>
It's only a guess but have you got the means of using Remote Desktop
Terminal Services Client or MSN Messenger Remote Assistance (As a
test) instead of PCAnywhere? I worked on the Laplink support line many
years ago and can imagine that this might be the issue and rings some
bells but things have changed since.
>
All the best,
>
Martin- Hide quoted text -
>
- Show quoted text -

The reason why I'm suggestin it is because PCAnywhere is perhaps
trying to synchromize files between the client and host (including
your .mdb) which is maybe still and remains in use by the Sync Process
when the VPN times out or disconnects.|||Actually, it usually happens after PCAnywhere has been closed. While
PCAnywhere is open, the VPN connection stays active. After I close
PCAnywhere, if I don't disconnect from the VPN, then eventually the VPN
connection times out.

So, a typical scenario is: open Access app connected to local SQL Server;
later, connect to VPN and do stuff via PCAnywhere; close PCAnywhere; later,
VPN connection disconnects, and then connection to local SQL Server fails.
Have to close and reopen MDB for it to work.

Strange...

"theintrepidfox" <theintrepidfox@.hotmail.comwrote in message
news:3e278590-302d-4549-82d4-2e12c0b51b1a@.i29g2000prf.googlegroups.com...

Quote:

Originally Posted by

On 26 Nov, 10:15, "Neil" <nos...@.nospam.netwrote:

Quote:

Originally Posted by

>I work on a local copy of a database (Access 2000 MDB with ODBC linked
>tables to a SQL 7 database). The SQL Server db I'm working with is on my
>C
>drive (MSDE). Occasionally I'll connect to a VPN to do something on a
>remote
>computer, using PC Anywhere to perform the task. Doesn't involve my front
>or
>back end at all, except that the computer I'm VPNing to has a SQL
>database
>running.
>>
>OK, so I'm using my db; I connect to the VPN, and do my thing.
>Everything's
>fine. However, if I then disconnect from the VPN (or if the VPN
>connection
>times out and disconnects itself), I then can no longer access my local
>SQL
>Server database. My Access application still works fine, as long as it
>doesn't have to look at any data. When it does have to look at data, I
>get
>ODBC call failed. I have to close and reopen my Access database, and then
>everything is fine.
>>
>So, it seems that, for some reason, when I connect to the VPN, my local
>SQL
>Server or the ODBC driver or something in the mix is looking at that
>remote
>database as part of what I'm using. Then, when the VPN connection is
>closed,
>it won't access my local database for some reason.
>>
>Oh, and my local database and the remote database both have the same
>name.
>So that may be part of the problem.
>>
>Any ideas as to what's going on?
>>
>Thanks!
>>
>Neil

>
It's only a guess but have you got the means of using Remote Desktop
Terminal Services Client or MSN Messenger Remote Assistance (As a
test) instead of PCAnywhere? I worked on the Laplink support line many
years ago and can imagine that this might be the issue and rings some
bells but things have changed since.
>
All the best,
>
Martin

|||"theintrepidfox" <theintrepidfox@.hotmail.comwrote in message
news:9cb60b5b-5160-4afe-8555-8ed2bed12b09@.s36g2000prg.googlegroups.com...

Quote:

Originally Posted by

On 27 Nov, 13:46, theintrepidfox <theintrepid...@.hotmail.comwrote:

Quote:

Originally Posted by

>On 26 Nov, 10:15, "Neil" <nos...@.nospam.netwrote:
>>
>>
>>
>>
>>

Quote:

Originally Posted by

I work on a local copy of a database (Access 2000 MDB with ODBC linked
tables to a SQL 7 database). The SQL Server db I'm working with is on
my C
drive (MSDE). Occasionally I'll connect to a VPN to do something on a
remote
computer, using PC Anywhere to perform the task. Doesn't involve my
front or
back end at all, except that the computer I'm VPNing to has a SQL
database
running.

>>

Quote:

Originally Posted by

OK, so I'm using my db; I connect to the VPN, and do my thing.
Everything's
fine. However, if I then disconnect from the VPN (or if the VPN
connection
times out and disconnects itself), I then can no longer access my local
SQL
Server database. My Access application still works fine, as long as it
doesn't have to look at any data. When it does have to look at data, I
get
ODBC call failed. I have to close and reopen my Access database, and
then
everything is fine.

>>

Quote:

Originally Posted by

So, it seems that, for some reason, when I connect to the VPN, my local
SQL
Server or the ODBC driver or something in the mix is looking at that
remote
database as part of what I'm using. Then, when the VPN connection is
closed,
it won't access my local database for some reason.

>>

Quote:

Originally Posted by

Oh, and my local database and the remote database both have the same
name.
So that may be part of the problem.

>>

Quote:

Originally Posted by

Any ideas as to what's going on?

>>

Quote:

Originally Posted by

Thanks!

>>

Quote:

Originally Posted by

Neil

>>
>It's only a guess but have you got the means of using Remote Desktop
>Terminal Services Client or MSN Messenger Remote Assistance (As a
>test) instead of PCAnywhere? I worked on the Laplink support line many
>years ago and can imagine that this might be the issue and rings some
>bells but things have changed since.
>>
>All the best,
>>
>Martin- Hide quoted text -
>>
>- Show quoted text -

>
The reason why I'm suggestin it is because PCAnywhere is perhaps
trying to synchromize files between the client and host (including
your .mdb) which is maybe still and remains in use by the Sync Process
when the VPN times out or disconnects.

Yeah, I don't think that's it. I tried connecting to the VPN without doing
anything else, and the results were the same. Something in SQL Server itself
is looking at that other server for some reason. Maybe because they both
have same-named databases. I don't know.

Thanks,

Neil

Local DB Affected By VPN

I work on a local copy of a database (Access 2000 MDB with ODBC linked
tables to a SQL 7 database). The SQL Server db I'm working with is on my C
drive (MSDE). Occasionally I'll connect to a VPN to do something on a remote
computer, using PC Anywhere to perform the task. Doesn't involve my front or
back end at all, except that the computer I'm VPNing to has a SQL database
running.
OK, so I'm using my db; I connect to the VPN, and do my thing. Everything's
fine. However, if I then disconnect from the VPN (or if the VPN connection
times out and disconnects itself), I then can no longer access my local SQL
Server database. My Access application still works fine, as long as it
doesn't have to look at any data. When it does have to look at data, I get
ODBC call failed. I have to close and reopen my Access database, and then
everything is fine.
So, it seems that, for some reason, when I connect to the VPN, my local SQL
Server or the ODBC driver or something in the mix is looking at that remote
database as part of what I'm using. Then, when the VPN connection is closed,
it won't access my local database for some reason.
Oh, and my local database and the remote database both have the same name.
So that may be part of the problem.
Any ideas as to what's going on?
Thanks!
NeilOn 26 Nov, 10:15, "Neil" <nos...@.nospam.net> wrote:
> I work on a local copy of a database (Access 2000 MDB with ODBC linked
> tables to a SQL 7 database). The SQL Server db I'm working with is on my C
> drive (MSDE). Occasionally I'll connect to a VPN to do something on a remo
te
> computer, using PC Anywhere to perform the task. Doesn't involve my front
or
> back end at all, except that the computer I'm VPNing to has a SQL database
> running.
> OK, so I'm using my db; I connect to the VPN, and do my thing. Everything'
s
> fine. However, if I then disconnect from the VPN (or if the VPN connection
> times out and disconnects itself), I then can no longer access my local SQ
L
> Server database. My Access application still works fine, as long as it
> doesn't have to look at any data. When it does have to look at data, I ge
t
> ODBC call failed. I have to close and reopen my Access database, and then
> everything is fine.
> So, it seems that, for some reason, when I connect to the VPN, my local SQ
L
> Server or the ODBC driver or something in the mix is looking at that remot
e
> database as part of what I'm using. Then, when the VPN connection is close
d,
> it won't access my local database for some reason.
> Oh, and my local database and the remote database both have the same name.
> So that may be part of the problem.
> Any ideas as to what's going on?
> Thanks!
> Neil
It's only a guess but have you got the means of using Remote Desktop
Terminal Services Client or MSN Messenger Remote Assistance (As a
test) instead of PCAnywhere? I worked on the Laplink support line many
years ago and can imagine that this might be the issue and rings some
bells but things have changed since.
All the best,
Martin|||On 27 Nov, 13:46, theintrepidfox <theintrepid...@.hotmail.com> wrote:
> On 26 Nov, 10:15, "Neil" <nos...@.nospam.net> wrote:
>
>
>
>
>
>
>
>
>
> It's only a guess but have you got the means of using Remote Desktop
> Terminal Services Client or MSN Messenger Remote Assistance (As a
> test) instead of PCAnywhere? I worked on the Laplink support line many
> years ago and can imagine that this might be the issue and rings some
> bells but things have changed since.
> All the best,
> Martin- Hide quoted text -
> - Show quoted text -
The reason why I'm suggestin it is because PCAnywhere is perhaps
trying to synchromize files between the client and host (including
your .mdb) which is maybe still and remains in use by the Sync Process
when the VPN times out or disconnects.|||Actually, it usually happens after PCAnywhere has been closed. While
PCAnywhere is open, the VPN connection stays active. After I close
PCAnywhere, if I don't disconnect from the VPN, then eventually the VPN
connection times out.
So, a typical scenario is: open Access app connected to local SQL Server;
later, connect to VPN and do stuff via PCAnywhere; close PCAnywhere; later,
VPN connection disconnects, and then connection to local SQL Server fails.
Have to close and reopen MDB for it to work.
Strange...
"theintrepidfox" <theintrepidfox@.hotmail.com> wrote in message
news:3e278590-302d-4549-82d4-2e12c0b51b1a@.i29g2000prf.googlegroups.com...
> On 26 Nov, 10:15, "Neil" <nos...@.nospam.net> wrote:
> It's only a guess but have you got the means of using Remote Desktop
> Terminal Services Client or MSN Messenger Remote Assistance (As a
> test) instead of PCAnywhere? I worked on the Laplink support line many
> years ago and can imagine that this might be the issue and rings some
> bells but things have changed since.
> All the best,
> Martin|||"theintrepidfox" <theintrepidfox@.hotmail.com> wrote in message
news:9cb60b5b-5160-4afe-8555-8ed2bed12b09@.s36g2000prg.googlegroups.com...
> On 27 Nov, 13:46, theintrepidfox <theintrepid...@.hotmail.com> wrote:
> The reason why I'm suggestin it is because PCAnywhere is perhaps
> trying to synchromize files between the client and host (including
> your .mdb) which is maybe still and remains in use by the Sync Process
> when the VPN times out or disconnects.
Yeah, I don't think that's it. I tried connecting to the VPN without doing
anything else, and the results were the same. Something in SQL Server itself
is looking at that other server for some reason. Maybe because they both
have same-named databases. I don't know.
Thanks,
Neil|||Not really, but you may try adding an entry to your host file pointing to
your local box and using the loopback IP. My vague guess is that possibly
you're getting into a situation where you get an IP through VPN and it
doesn't resolve the new IP when you get disconnected. Mind you, that's just
a guess, but it's all I've got right now.
Anyway, try the host file thing and see if that does anything for you.
"Neil" wrote:

> I work on a local copy of a database (Access 2000 MDB with ODBC linked
> tables to a SQL 7 database). The SQL Server db I'm working with is on my C
> drive (MSDE). Occasionally I'll connect to a VPN to do something on a remo
te
> computer, using PC Anywhere to perform the task. Doesn't involve my front
or
> back end at all, except that the computer I'm VPNing to has a SQL database
> running.
> OK, so I'm using my db; I connect to the VPN, and do my thing. Everything'
s
> fine. However, if I then disconnect from the VPN (or if the VPN connection
> times out and disconnects itself), I then can no longer access my local SQ
L
> Server database. My Access application still works fine, as long as it
> doesn't have to look at any data. When it does have to look at data, I ge
t
> ODBC call failed. I have to close and reopen my Access database, and then
> everything is fine.
> So, it seems that, for some reason, when I connect to the VPN, my local SQ
L
> Server or the ODBC driver or something in the mix is looking at that remot
e
> database as part of what I'm using. Then, when the VPN connection is close
d,
> it won't access my local database for some reason.
> Oh, and my local database and the remote database both have the same name.
> So that may be part of the problem.
> Any ideas as to what's going on?
> Thanks!
> Neil
>
>

Local copy of Remote Database?

Is there are direct and simply way to backup a database hosted on a
remote machine to my local workstation without involving sharing out
the hardware(eg: A:\ or some folder in local hdd) or even creating new
accounts which has the admin rights?If you are taking a backup, the backup path is always related to the
server, so you either can backup on a local drive OR backup the data on
a network share (UNC) where both machines have access to. Another copy
of a local database can be done using the DTS wizrad and copying all
objects and data via SQL Server objects copy.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--|||You can use net use to map a drive and use it for backup.
Regards
Amish Shah

Local copy of Remote Database?

Is there are direct and simply way to backup a database hosted on a
remote machine to my local workstation without involving sharing out
the hardware(eg: A:\ or some folder in local hdd) or even creating new
accounts which has the admin rights?If you are taking a backup, the backup path is always related to the
server, so you either can backup on a local drive OR backup the data on
a network share (UNC) where both machines have access to. Another copy
of a local database can be done using the DTS wizrad and copying all
objects and data via SQL Server objects copy.
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--|||You can use net use to map a drive and use it for backup.
Regards
Amish Shah

Local copy

Hi,
i have a Sqlserver 2000 database on a webserver. Now i want to move this
database to another provider (server). I have restricted access to the
database. What is the best way to retrieve all the data to a local pc ? What
i need is a sort of Backup to local pc. I have asked the provider to put
this on a cd-rom, but he refuse this.
GL.A quick way is to : create a database on a local server, transfer all
objects/data to the local server copy
Jack Vamvas
________________________________________
__________________________
Receive free SQL tips - register at www.ciquery.com/sqlserver.htm
SQL Server Performance Audit - check www.ciquery.com/sqlserver_audit.htm
New article by Jack Vamvas - SQL and Markov Chains -
www.ciquery.com/articles/art_04.asp
"Grard Leclercq" <gerard.leclercq@.pas-de-mail.fr> wrote in message
news:UUNDf.225782$bM3.7399534@.phobos.telenet-ops.be...
> Hi,
> i have a Sqlserver 2000 database on a webserver. Now i want to move this
> database to another provider (server). I have restricted access to the
> database. What is the best way to retrieve all the data to a local pc ?
What
> i need is a sort of Backup to local pc. I have asked the provider to put
> this on a cd-rom, but he refuse this.
> GL.
>|||I know this issue, the same for my provider, the best is (as far as you
don=B4t store blob columns) to script the data out to a script file and
reapply the data to your destination database, This worked fine for me.
See this script here for more information:
http://vyaskn.tripod.com/code.htm#inserts
HTH, Jens Suessmeyer.|||Thank you, finally the provider have ask me 150 euro for a copy on CD. But
the next time i keep your advise in mind.
Thx - GL
"Jens" <Jens@.sqlserver2005.de> schreef in bericht
news:1138733350.602238.280700@.g44g2000cwa.googlegroups.com...
I know this issue, the same for my provider, the best is (as far as you
dont store blob columns) to script the data out to a script file and
reapply the data to your destination database, This worked fine for me.
See this script here for more information:
http://vyaskn.tripod.com/code.htm#inserts
HTH, Jens Suessmeyer.