database errors: moved

Showing posts with label moved. Show all posts

Thursday, March 22, 2012

Crystal reports problem

I also posted this to the CR newsgroup, but I think it might be an MSDE
problem also.
We recently moved several Access databases to an instance of MSDE. We use
VB .Net for program development. Upon running one of the programs a dialog
box now pops up alerting us to enter a user name and password. I searched
the Business Solutions help and found that the database server needs to be
set up with a trusted connection. I thought I already did this through the
data connection of the VS IDE.
Is there something more than I have to do on the MSDE side?
Thanks for any useful information.
Brad
hi Brad,
"Brad" <ballison@.ukcdogs.com> ha scritto nel messaggio
news:eRE7fiSkEHA.3612@.TK2MSFTNGP12.phx.gbl...
> I also posted this to the CR newsgroup, but I think it might be an MSDE
> problem also.
> We recently moved several Access databases to an instance of MSDE. We
use
> VB .Net for program development. Upon running one of the programs a
dialog
> box now pops up alerting us to enter a user name and password. I searched
> the Business Solutions help and found that the database server needs to be
> set up with a trusted connection. I thought I already did this through
the
> data connection of the VS IDE.
> Is there something more than I have to do on the MSDE side?
> Thanks for any useful information.
MSDE is usually installed allowing *only* trusted connections, and you have
to force the parameter SECURITYMODE=SQL at install time in order to allow
SQL Server authenticated connection..
chek your registry at
HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer
or
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\InstanceName\MSSQLServer
at the
LoginMode key
a value of 2 will allow both, where 1 only allows trusted connections
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Andrea,
Thank you for the response, however in researching this problem I did see a
knowleddge base article about changing the key to 2 which I already did and
I still am having the same problem.
Thanks,
Brad
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:2prjfcFo4pukU1@.uni-berlin.de...
> hi Brad,
> "Brad" <ballison@.ukcdogs.com> ha scritto nel messaggio
> news:eRE7fiSkEHA.3612@.TK2MSFTNGP12.phx.gbl...
> use
> dialog
> the
> MSDE is usually installed allowing *only* trusted connections, and you
> have
> to force the parameter SECURITYMODE=SQL at install time in order to allow
> SQL Server authenticated connection..
> chek your registry at
> HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer
> or
> HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\InstanceName\MSSQLServer
> at the
> LoginMode key
> a value of 2 will allow both, where 1 only allows trusted connections
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
sql

Tuesday, March 20, 2012

Crystal Reports 8 User session expired error

Hi,
As we are migrating from NT server to Win 2003 server. web applications are moved over from nt as well. I am facing problem with one the web apps which uses crystal reports 8. "User Session expired" error msg is popping out when we try to export the report into any supported format such html, excel, word etc.. The report comes up no issues..however unable to use export option.

I went through the business objects .pdf for user session expired err msg...but nothing helped. i am still stuck with this problem.
can anybody help me here pls.

FYI...It's a ASP/VB web appl using crystal reports 8.0 on Win 2003 machine.

thanks
DRM.Hello,

Further to my earlier msg, after commenting out the default error msg "User Session expired" i got this error msg

"The Report was not Exported. The selected report format may be disabled on the server" actually this is common msg coming up for all export formats...available in crystal 8.0 version.

Therefore, any ideas how to check/verify and Enable/Disable this on server?

ur help on this will be greatly appreciated.

thanks a ton in adv.

Cheers,
muki

Thursday, February 16, 2012

cross server update problem

The system has worked for two years.

SQL Server 2000 runs on Windows 2000 Server “A”.

Another instance of SQL Server 2000 was moved from Windows 2000 Server “B” old to Windows 2003 Server “B” new, by restoring a backed up copy from old to new.

The system has cross server updates, where Server “A” is updating records in very large tables on Server “B”.

After the move from Server “B” old to Server “B” new, suddenly the cross server updates fail, but only when they are conducted within a Begin and Commit Transaction batch.

The system works when I remove the Begin and Commit Transaction, and no longer have them run in a batch.

Also, I had a cross server update, having “A” update records in “B”, from a delete trigger residing on “A” table.Deletes against the “A” table fail so long as the trigger remains.Once I remove the delete trigger from the “A” table, I can now delete records on the “A” table.

Thanks. Dotnet Fellow

Have you checked to make sure that you have a linked server set up on the machines, When moveing you might not have moved the config for the linked server.

|||

First step is to make sure that the Distributed Transaction Coordinator service is started on both servers.

Next, if they are, can you run a statement in QA and send the error message?

|||

DTC is running on both computers. There is no error message returned. Just hangs for hours until a timeout is encountered. Looking at it through Profiler Trace it appears that no activity is occurring on either server once the transaction is begun. Or, in the case of the delete triggers, it appears that everything comes to a complete standstill once the delete statement is executed. Again, once I remove the begin transaction, or once I remove the trigger, things move along normally.

Hey Davidson, what happened to Chuck Hawkins?

|||

All servers involved, old and new, have a default collation of SQL_Latin1_General_CP1_CI_AS.

My Cross Server update that I execute on Server "A" is below, where

@.p_str_source_workspace VARCHAR(50) = 'vit16.ais70.dbo.', and
@.p_str_destination_workspace VARCHAR(50) = 'vit2.opus.dbo.'

Again, it doesn't work when I uncomment the BEGIN TRANSACTION

/*
Update the source database, ensure that the archived flag is accurately marked as 'N' if the record does not yet exist in Opus.
*/

SELECT @.l_str_update = ' UPDATE ' + @.p_str_source_workspace + 'pr_history SET archived = ''N'' FROM ' + @.p_str_source_workspace + 'pr_history as pr0 WHERE archived = ''Y'' AND pr0.pr_hist_search NOT IN (SELECT pr_hist_search FROM ' + @.p_str_destination_workspace + 'pr_history)'

--BEGIN TRANSACTION

EXEC (@.l_str_update)

Thanks for keeping me in mind Erland.

|||There are new network DTC security "features" in Windows 2003 Server. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/2627a956-60b3-4d26-bc04-e0676ec97786.asp

This might you get the specific settings right, if this is indeed the problem: http://www.prophecie.co.uk/Default.aspx?dc=200509

Steve Kass
Drew University
http://www.stevekass.com

cross server update problem

The system has worked for two years.
SQL Server 2000 runs on Windows 2000 Server "A".
Another instance of SQL Server 2000 was moved from Windows 2000 Server
"B" old to Windows 2003 Server "B" new, by restoring a backed
up copy from old to new.
The system has cross server updates, where Server "A" is updating
records in very large tables on Server "B".
After the move from Server "B" old to Server "B" new, suddenly
the cross server updates fail, but only when they are conducted within
a Begin and Commit Transaction batch.
The system works when I remove the Begin and Commit Transaction, and no
longer have them run in a batch.
Also, I had a cross server update, having "A" update records in
"B", from a delete trigger residing on "A" table. Deletes
against the "A" table fail so long as the trigger remains. Once I
remove the delete trigger from the "A" table, I can now delete
records on the "A" table.
Thanks. Dotnet Fellowdotnetfellow@.yahoo.com wrote:
> The system has worked for two years.
> SQL Server 2000 runs on Windows 2000 Server "A".
> Another instance of SQL Server 2000 was moved from Windows 2000 Server
> "B" old to Windows 2003 Server "B" new, by restoring a backed
> up copy from old to new.
> The system has cross server updates, where Server "A" is updating
> records in very large tables on Server "B".
> After the move from Server "B" old to Server "B" new, suddenly
> the cross server updates fail, but only when they are conducted within
> a Begin and Commit Transaction batch.
> The system works when I remove the Begin and Commit Transaction, and no
> longer have them run in a batch.
> Also, I had a cross server update, having "A" update records in
> "B", from a delete trigger residing on "A" table. Deletes
> against the "A" table fail so long as the trigger remains. Once I
> remove the delete trigger from the "A" table, I can now delete
> records on the "A" table.
> Thanks. Dotnet Fellow
>
Transactions that involve multiple servers are called "distributed"
transactions, and rely on the MSDTC service to function. On Windows
2003 Server, MSDTC refuses network connections by default. Start here:
http://support.microsoft.com/kb/899191/
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||DTC is running on both computers. There is no error message returned.
Just hangs for hours until a timeout is encountered. Looking at it
through Profiler Trace it appears that no activity is occurring on
either server once the transaction is begun. Or, in the case of the
delete triggers, it appears that everything comes to a complete
standstill once the delete statement is executed. Again, once I remove
the begin transaction, or once I remove the trigger, things move along
normally.|||All servers involved, old and new, have a default collation of
SQL_Latin1_General_CP1_CI_AS.
My Cross Server update that I execute on Server "A" is below, where
@.p_str_source_workspace VARCHAR(50) = 'vit16.ais70.dbo.', and
@.p_str_destination_workspace VARCHAR(50) = 'vit2.opus.dbo.'
--
/*
Update the source database, ensure that the archived flag is accurately
marked as 'N' if the record does not yet exist in Opus.
*/
SELECT @.l_str_update = ' UPDATE ' + @.p_str_source_workspace +
'pr_history SET archived = ''N'' FROM ' + @.p_str_source_workspace +
'pr_history as pr0 WHERE archived = ''Y'' AND pr0.pr_hist_search NOT IN
(SELECT pr_hist_search FROM ' + @.p_str_destination_workspace +
'pr_history)'
--BEGIN TRANSACTION
EXEC (@.l_str_update)
--

cross server update problem

The system has worked for two years.

SQL Server 2000 runs on Windows 2000 Server “A”.

Another instance of SQL Server 2000 was moved from Windows 2000 Server “B” old to Windows 2003 Server “B” new, by restoring a backed up copy from old to new.

The system has cross server updates, where Server “A” is updating records in very large tables on Server “B”.

After the move from Server “B” old to Server “B” new, suddenly the cross server updates fail, but only when they are conducted within a Begin and Commit Transaction batch.

The system works when I remove the Begin and Commit Transaction, and no longer have them run in a batch.

Thanks. Dotnet Fellow

Have you checked to make sure that you have a linked server set up on the machines, When moveing you might not have moved the config for the linked server.

|||

First step is to make sure that the Distributed Transaction Coordinator service is started on both servers.

Next, if they are, can you run a statement in QA and send the error message?

|||

Hey Davidson, what happened to Chuck Hawkins?

|||

All servers involved, old and new, have a default collation of SQL_Latin1_General_CP1_CI_AS.

My Cross Server update that I execute on Server "A" is below, where

@.p_str_source_workspace VARCHAR(50) = 'vit16.ais70.dbo.', and
@.p_str_destination_workspace VARCHAR(50) = 'vit2.opus.dbo.'

Again, it doesn't work when I uncomment the BEGIN TRANSACTION

/*
Update the source database, ensure that the archived flag is accurately marked as 'N' if the record does not yet exist in Opus.
*/

--BEGIN TRANSACTION

EXEC (@.l_str_update)

Thanks for keeping me in mind Erland.

|||There are new network DTC security "features" in Windows 2003 Server. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/2627a956-60b3-4d26-bc04-e0676ec97786.asp

This might you get the specific settings right, if this is indeed the problem: http://www.prophecie.co.uk/Default.aspx?dc=200509

Steve Kass
Drew University
http://www.stevekass.com

cross server update problem

The system has worked for two years.
SQL Server 2000 runs on Windows 2000 Server "A".
Another instance of SQL Server 2000 was moved from Windows 2000 Server
"B" old to Windows 2003 Server "B" new, by restoring a backed
up copy from old to new.
The system has cross server updates, where Server "A" is updating
records in very large tables on Server "B".
After the move from Server "B" old to Server "B" new, suddenly
the cross server updates fail, but only when they are conducted within
a Begin and Commit Transaction batch.
The system works when I remove the Begin and Commit Transaction, and no
longer have them run in a batch.
Also, I had a cross server update, having "A" update records in
"B", from a delete trigger residing on "A" table. Deletes
against the "A" table fail so long as the trigger remains. Once I
remove the delete trigger from the "A" table, I can now delete
records on the "A" table.
Thanks. Dotnet Fellowdotnetfellow@.yahoo.com wrote:
> The system has worked for two years.
> SQL Server 2000 runs on Windows 2000 Server "A".
> Another instance of SQL Server 2000 was moved from Windows 2000 Server
> "B" old to Windows 2003 Server "B" new, by restoring a backed
> up copy from old to new.
> The system has cross server updates, where Server "A" is updating
> records in very large tables on Server "B".
> After the move from Server "B" old to Server "B" new, suddenly
> the cross server updates fail, but only when they are conducted within
> a Begin and Commit Transaction batch.
> The system works when I remove the Begin and Commit Transaction, and no
> longer have them run in a batch.
> Also, I had a cross server update, having "A" update records in
> "B", from a delete trigger residing on "A" table. Deletes
> against the "A" table fail so long as the trigger remains. Once I
> remove the delete trigger from the "A" table, I can now delete
> records on the "A" table.
> Thanks. Dotnet Fellow
>
Transactions that involve multiple servers are called "distributed"
transactions, and rely on the MSDTC service to function. On Windows
2003 Server, MSDTC refuses network connections by default. Start here:
http://support.microsoft.com/kb/899191/
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||DTC is running on both computers. There is no error message returned.
Just hangs for hours until a timeout is encountered. Looking at it
through Profiler Trace it appears that no activity is occurring on
either server once the transaction is begun. Or, in the case of the
delete triggers, it appears that everything comes to a complete
standstill once the delete statement is executed. Again, once I remove
the begin transaction, or once I remove the trigger, things move along
normally.|||All servers involved, old and new, have a default collation of
SQL_Latin1_General_CP1_CI_AS.
My Cross Server update that I execute on Server "A" is below, where
@.p_str_source_workspace VARCHAR(50) = 'vit16.ais70.dbo.', and
@.p_str_destination_workspace VARCHAR(50) = 'vit2.opus.dbo.'
/*
Update the source database, ensure that the archived flag is accurately
marked as 'N' if the record does not yet exist in Opus.
*/
SELECT @.l_str_update = ' UPDATE ' + @.p_str_source_workspace +
'pr_history SET archived = ''N'' FROM ' + @.p_str_source_workspace +
'pr_history as pr0 WHERE archived = ''Y'' AND pr0.pr_hist_search NOT IN
(SELECT pr_hist_search FROM ' + @.p_str_destination_workspace +
'pr_history)'
--BEGIN TRANSACTION
EXEC (@.l_str_update)

cross server update problem

The system has worked for two years.

SQL Server 2000 runs on Windows 2000 Server "A".

Another instance of SQL Server 2000 was moved from Windows 2000 Server
"B" old to Windows 2003 Server "B" new, by restoring a backed
up copy from old to new.

The system has cross server updates, where Server "A" is updating
records in very large tables on Server "B".

After the move from Server "B" old to Server "B" new, suddenly
the cross server updates fail, but only when they are conducted within
a Begin and Commit Transaction batch.

The system works when I remove the Begin and Commit Transaction, and no
longer have them run in a batch.

Also, I had a cross server update, having "A" update records in
"B", from a delete trigger residing on "A" table. Deletes
against the "A" table fail so long as the trigger remains. Once I
remove the delete trigger from the "A" table, I can now delete
records on the "A" table.

Thanks. Dotnet Fellow(dotnetfellow@.yahoo.com) writes:

Quote:

Originally Posted by

The system has worked for two years.
>
SQL Server 2000 runs on Windows 2000 Server "A".
>
Another instance of SQL Server 2000 was moved from Windows 2000 Server
"B" old to Windows 2003 Server "B" new, by restoring a backed
up copy from old to new.
>
The system has cross server updates, where Server "A" is updating
records in very large tables on Server "B".
>
After the move from Server "B" old to Server "B" new, suddenly
the cross server updates fail, but only when they are conducted within
a Begin and Commit Transaction batch.
>
The system works when I remove the Begin and Commit Transaction, and no
longer have them run in a batch.

Any error message you could share with us?

Since it works without a transaction, it sounds as if DTC is not running
on the new server B.

Quote:

Originally Posted by

A trigger always operates in a transaction defined by the statement that
fired it, so this is consistent with the above.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||DTC is running on both computers.|||There is no error message returned. Just hangs for hours until a
timeout is encountered. Looking at it through Profiler Trace it
appears that no activity is occurring on either server once the
transaction is begun. Or, in the case of the delete triggers, it
appears that everything comes to a complete standstill once the delete
statement is executed.|||(dotnetfellow@.yahoo.com) writes:

Quote:

Originally Posted by

There is no error message returned. Just hangs for hours until a
timeout is encountered. Looking at it through Profiler Trace it
appears that no activity is occurring on either server once the
transaction is begun. Or, in the case of the delete triggers, it
appears that everything comes to a complete standstill once the delete
statement is executed.

Let me guess: the source server runs Windows 2000, and the target server
runs Windows 2003? Where as the server you replaced ran Windows 2000?

No, I don't know anything. But I think I've seen this scenario at work. As
that has only been with development and test servers I have not dug into it.

But chance had it that one of our customer ran into precisely this
problem today. They have a brand-new server (which I assume runs Win 2003),
and in one place our gateway database that runs on another server (which
I suspect runs Win 2000) tries to use INSERT-EXEC to the linked server.
Worked find Friday. Today it just hung. SQL 2000 on both machines.

We will probably open a case with Microsoft on this. I suspect it's one
of these RTFM things, but I just don't know which manual. My gut feeling
is that this is a DTC problem. Maybe as simple, as opening the correct
port in Windows firewall. Whatever, I believe it's more a Windows problem
than an SQL Server problem per se.

If we open a case, and I hear about the resolution, I'll try to post
back.

My Cross Server update that I execute on Server "A" is below, where

@.p_str_source_workspace VARCHAR(50) = 'vit16.ais70.dbo.', and
@.p_str_destination_workspace VARCHAR(50) = 'vit2.opus.dbo.'

Again, it doesn't work when I uncomment the BEGIN TRANSACTION

---

/*
Update the source database, ensure that the archived flag is accurately
marked as 'N' if the record does not yet exist in Opus.
*/

SELECT @.l_str_update = ' UPDATE ' + @.p_str_source_workspace +
'pr_history SET archived = ''N'' FROM ' + @.p_str_source_workspace +
'pr_history as pr0 WHERE archived = ''Y'' AND pr0.pr_hist_search NOT IN
(SELECT pr_hist_search FROM ' + @.p_str_destination_workspace +
'pr_history)'

--BEGIN TRANSACTION

EXEC (@.l_str_update)

---

Thanks for keeping me in mind Erland.|||(dotnetfellow@.yahoo.com) writes:

Quote:

Originally Posted by

All servers involved, old and new, have a default collation of
SQL_Latin1_General_CP1_CI_AS.

I would not expect collations to have anything to do with it. In fact, as I
said, my feeling is that it is not really an SQL Server issue, but a Windows
issue.

You did not confirm my guesses about the operating system. By the way,
when you replaced B, did you give the same IP address to the new B
server? There is another potential source for problem, some reference
to the old machine lingering around.

I spoke to my colleague who has been in touch with Microsoft. Apparently
they did not just say "did you check that...", but instead they asked tim
to send logs and similar information.

In our case, it turned out that the machine from which we made the
connection is running SQL 2000 SP2 and Windows 2000 SP2. The Microsoft
engineer suggested that the SQL Server should be upgraded to SQL 2000 SP4
and Windows 2000 SP4. Whether this alone will resolve the issue, I don't
know yet. The simple reason the Support Professional wanted us to upgrade
is that they don't support neither SQL 2000 SP2 nor Win 2000 SP2.

On the server you are connecting to, open Component Services and select
properties for My Computer. Go to the MS DTC tab. To the lower left, there
is a button Security Configuration. This opens a new dialogue. In this
dialogue, enable 1) Network DTC Access. 2) Allow Inbound. 3) No
Authentication Required.

Really what the implication of these settings are from the security side
point of view, I don't know.

Windows 2003 R2 has new DTC protection measures built-in and enabled
by default, since MSDTC is used for SQL Server purposes and this
machines don't have internet access there are no problem in set no
authentication required. In future if you upgrade your Windows 2000
machine to Windows 2003 SP1 or Windows 2003 R2 and they are in same
domain (this is a requirement) you can activate mutual authentication
in MSDTC and will not have any problem.

These steps are not documented but I let you some recommendations to
troubleshooting MSDTC problems.

1) Put security setting at the minimum level

2) Enable MSDTC logging and verify if anything appears on log file

3) Use DTCPing utility to avoid firewall problems

4) Verify if RPC is started before MSDTC and SQL Server is started
after MSDTC and RPC services.

5) Verify in SQL Server error log that MSDTC started with success

6) Please verify if you have COM/COM+ components enabled and with all
hot fixes installed

Thursday, March 22, 2012

Crystal reports problem

Tuesday, March 20, 2012

Crystal Reports 8 User session expired error

Thursday, February 16, 2012

cross server update problem

cross server update problem

cross server update problem

cross server update problem

cross server update problem

database errors

Blog Archive

About Me