I've been struggling to put together an install setup for an app on a pocket
pc. This app accesses a network SQL 2005 server.
I finally got things working - found some .CAB's that needed to be installed
on the PPC for SQL CE and SQL CLIENT.
But now I'm getting an odd error. In my SQL connection string I'm
specifying DATASOURCE=SPSERVER (which is the network server for SQL 2005 on
our domain). But instead it's connecting to a laptop SQL 2000 instance -
laptop name is FPS-LAP-SZ. I've googled for a bug like this and found no
info.
How do I guarantee the latest .CAB's for SQL CE and SQL CLIENT for my PPC
install?Hello Steve!
Correction: It's "Data Source=" or "Server=" not "DATASOURCE="
You may find the latest version of SQL Server CE from the following link:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=85e0c3ce-3fa1-453a-8ce9-af6ca20946c3
Ekrem Ã?nsoy
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:7508FAC3-F20E-4AB9-85AF-8E02782751D2@.microsoft.com...
> I've been struggling to put together an install setup for an app on a
> pocket
> pc. This app accesses a network SQL 2005 server.
> I finally got things working - found some .CAB's that needed to be
> installed
> on the PPC for SQL CE and SQL CLIENT.
> But now I'm getting an odd error. In my SQL connection string I'm
> specifying DATASOURCE=SPSERVER (which is the network server for SQL 2005
> on
> our domain). But instead it's connecting to a laptop SQL 2000 instance -
> laptop name is FPS-LAP-SZ. I've googled for a bug like this and found no
> info.
> How do I guarantee the latest .CAB's for SQL CE and SQL CLIENT for my PPC
> install?|||I have "DATA SOURCE=SPSERVER" - I typed it wrong in my post.
How about the latest download for SQL CLIENT for PPC?
"Ekrem Ã?nsoy" wrote:
> Hello Steve!
>
> Correction: It's "Data Source=" or "Server=" not "DATASOURCE="
> You may find the latest version of SQL Server CE from the following link:
> http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=85e0c3ce-3fa1-453a-8ce9-af6ca20946c3
>
> --
> Ekrem Ã?nsoy
>
> "Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
> news:7508FAC3-F20E-4AB9-85AF-8E02782751D2@.microsoft.com...
> > I've been struggling to put together an install setup for an app on a
> > pocket
> > pc. This app accesses a network SQL 2005 server.
> >
> > I finally got things working - found some .CAB's that needed to be
> > installed
> > on the PPC for SQL CE and SQL CLIENT.
> >
> > But now I'm getting an odd error. In my SQL connection string I'm
> > specifying DATASOURCE=SPSERVER (which is the network server for SQL 2005
> > on
> > our domain). But instead it's connecting to a laptop SQL 2000 instance -
> > laptop name is FPS-LAP-SZ. I've googled for a bug like this and found no
> > info.
> >
> > How do I guarantee the latest .CAB's for SQL CE and SQL CLIENT for my PPC
> > install?
>
Showing posts with label install. Show all posts
Showing posts with label install. Show all posts
Sunday, March 25, 2012
Sunday, February 19, 2012
DATABASE= or INITIAL CATALOG=?
I'm setting up a DSN for a new SQL Server install, and had some problems with
an existing Access app. Every query resulted in an "object not found", and
after a little poking about it became clear that it was because the app was
connecting to "master" instead of our database.
The connection string in Access used "Database=[our database name]". Does
this actually work? Or did the app only work in the past because the default
database for that login was set to ours?
Is there a difference between DATABASE (which I inherited) and INITIAL
CATALOG?
Yes, Database=YourDatabase does actually work.
Initial catalog is generally used when connecting with an
OLE DB provider.
Database is generally used when connecting with an ODBC
driver.
The following is a good resource for connection strings:
http://www.able-consulting.com/ADO_Conn.htm
-Sue
On Wed, 24 Nov 2004 07:37:35 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>I'm setting up a DSN for a new SQL Server install, and had some problems with
>an existing Access app. Every query resulted in an "object not found", and
>after a little poking about it became clear that it was because the app was
>connecting to "master" instead of our database.
>The connection string in Access used "Database=[our database name]". Does
>this actually work? Or did the app only work in the past because the default
>database for that login was set to ours?
>Is there a difference between DATABASE (which I inherited) and INITIAL
>CATALOG?
|||"Sue Hoegemeier" wrote:
> Yes, Database=YourDatabase does actually work.
> Initial catalog is generally used when connecting with an
> OLE DB provider.
Hmmm. That being the case can you suggest any other reason for this problem?
The application logs into the correct server and attaches to master, even
though I say database=mydatabase in the connection string.
|||Using DSNs and connections strings is kind of a waste in my
opinion and can make the issues more convoluted. I have no
idea how the DSN and connection strings are being used but I
would just get rid of the DSN. You introduce maintenance
issues as well as you have your connection string in a DSN
and in code. So I'd eliminate that and just use dsn-less
connections.
Make sure the user exists in the database and can actually
access the database.
-Sue
On Wed, 24 Nov 2004 08:37:04 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>"Sue Hoegemeier" wrote:
>
>Hmmm. That being the case can you suggest any other reason for this problem?
>The application logs into the correct server and attaches to master, even
>though I say database=mydatabase in the connection string.
an existing Access app. Every query resulted in an "object not found", and
after a little poking about it became clear that it was because the app was
connecting to "master" instead of our database.
The connection string in Access used "Database=[our database name]". Does
this actually work? Or did the app only work in the past because the default
database for that login was set to ours?
Is there a difference between DATABASE (which I inherited) and INITIAL
CATALOG?
Yes, Database=YourDatabase does actually work.
Initial catalog is generally used when connecting with an
OLE DB provider.
Database is generally used when connecting with an ODBC
driver.
The following is a good resource for connection strings:
http://www.able-consulting.com/ADO_Conn.htm
-Sue
On Wed, 24 Nov 2004 07:37:35 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>I'm setting up a DSN for a new SQL Server install, and had some problems with
>an existing Access app. Every query resulted in an "object not found", and
>after a little poking about it became clear that it was because the app was
>connecting to "master" instead of our database.
>The connection string in Access used "Database=[our database name]". Does
>this actually work? Or did the app only work in the past because the default
>database for that login was set to ours?
>Is there a difference between DATABASE (which I inherited) and INITIAL
>CATALOG?
|||"Sue Hoegemeier" wrote:
> Yes, Database=YourDatabase does actually work.
> Initial catalog is generally used when connecting with an
> OLE DB provider.
Hmmm. That being the case can you suggest any other reason for this problem?
The application logs into the correct server and attaches to master, even
though I say database=mydatabase in the connection string.
|||Using DSNs and connections strings is kind of a waste in my
opinion and can make the issues more convoluted. I have no
idea how the DSN and connection strings are being used but I
would just get rid of the DSN. You introduce maintenance
issues as well as you have your connection string in a DSN
and in code. So I'd eliminate that and just use dsn-less
connections.
Make sure the user exists in the database and can actually
access the database.
-Sue
On Wed, 24 Nov 2004 08:37:04 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>"Sue Hoegemeier" wrote:
>
>Hmmm. That being the case can you suggest any other reason for this problem?
>The application logs into the correct server and attaches to master, even
>though I say database=mydatabase in the connection string.
DATABASE= or INITIAL CATALOG=?
I'm setting up a DSN for a new SQL Server install, and had some problems wit
h
an existing Access app. Every query resulted in an "object not found", and
after a little poking about it became clear that it was because the app was
connecting to "master" instead of our database.
The connection string in Access used "Database=[our database name]". Doe
s
this actually work? Or did the app only work in the past because the default
database for that login was set to ours?
Is there a difference between DATABASE (which I inherited) and INITIAL
CATALOG?Yes, Database=YourDatabase does actually work.
Initial catalog is generally used when connecting with an
OLE DB provider.
Database is generally used when connecting with an ODBC
driver.
The following is a good resource for connection strings:
http://www.able-consulting.com/ADO_Conn.htm
-Sue
On Wed, 24 Nov 2004 07:37:35 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>I'm setting up a DSN for a new SQL Server install, and had some problems wi
th
>an existing Access app. Every query resulted in an "object not found", and
>after a little poking about it became clear that it was because the app was
>connecting to "master" instead of our database.
>The connection string in Access used "Database=[our database name]". Do
es
>this actually work? Or did the app only work in the past because the defaul
t
>database for that login was set to ours?
>Is there a difference between DATABASE (which I inherited) and INITIAL
>CATALOG?|||"Sue Hoegemeier" wrote:
> Yes, Database=YourDatabase does actually work.
> Initial catalog is generally used when connecting with an
> OLE DB provider.
Hmmm. That being the case can you suggest any other reason for this problem?
The application logs into the correct server and attaches to master, even
though I say database=mydatabase in the connection string.|||Using DSNs and connections strings is kind of a waste in my
opinion and can make the issues more convoluted. I have no
idea how the DSN and connection strings are being used but I
would just get rid of the DSN. You introduce maintenance
issues as well as you have your connection string in a DSN
and in code. So I'd eliminate that and just use dsn-less
connections.
Make sure the user exists in the database and can actually
access the database.
-Sue
On Wed, 24 Nov 2004 08:37:04 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>"Sue Hoegemeier" wrote:
>
>Hmmm. That being the case can you suggest any other reason for this problem
?
>The application logs into the correct server and attaches to master, even
>though I say database=mydatabase in the connection string.
h
an existing Access app. Every query resulted in an "object not found", and
after a little poking about it became clear that it was because the app was
connecting to "master" instead of our database.
The connection string in Access used "Database=[our database name]". Doe
s
this actually work? Or did the app only work in the past because the default
database for that login was set to ours?
Is there a difference between DATABASE (which I inherited) and INITIAL
CATALOG?Yes, Database=YourDatabase does actually work.
Initial catalog is generally used when connecting with an
OLE DB provider.
Database is generally used when connecting with an ODBC
driver.
The following is a good resource for connection strings:
http://www.able-consulting.com/ADO_Conn.htm
-Sue
On Wed, 24 Nov 2004 07:37:35 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>I'm setting up a DSN for a new SQL Server install, and had some problems wi
th
>an existing Access app. Every query resulted in an "object not found", and
>after a little poking about it became clear that it was because the app was
>connecting to "master" instead of our database.
>The connection string in Access used "Database=[our database name]". Do
es
>this actually work? Or did the app only work in the past because the defaul
t
>database for that login was set to ours?
>Is there a difference between DATABASE (which I inherited) and INITIAL
>CATALOG?|||"Sue Hoegemeier" wrote:
> Yes, Database=YourDatabase does actually work.
> Initial catalog is generally used when connecting with an
> OLE DB provider.
Hmmm. That being the case can you suggest any other reason for this problem?
The application logs into the correct server and attaches to master, even
though I say database=mydatabase in the connection string.|||Using DSNs and connections strings is kind of a waste in my
opinion and can make the issues more convoluted. I have no
idea how the DSN and connection strings are being used but I
would just get rid of the DSN. You introduce maintenance
issues as well as you have your connection string in a DSN
and in code. So I'd eliminate that and just use dsn-less
connections.
Make sure the user exists in the database and can actually
access the database.
-Sue
On Wed, 24 Nov 2004 08:37:04 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:
>"Sue Hoegemeier" wrote:
>
>Hmmm. That being the case can you suggest any other reason for this problem
?
>The application logs into the correct server and attaches to master, even
>though I say database=mydatabase in the connection string.
Friday, February 17, 2012
Database version - can't install SP1
I have a SQL Server 2005 install with the 64-bit Database Server, but
I've had to install the 32-bit version of Reporting Services, since IIS
is running in 32-bit mode. Everything's green in the Configuration
Tool, but when I go to http://server/reportserver, I get the following
error:
The version of the report server database is either in a format that is
not valid, or it cannot be read. The found version is 'C.0.8.43'. The
expected version is 'C.0.8.40'. To continue, update the version of the
report server database and verify access rights.
(rsInvalidReportServerDatabase)
I think the problem is that I have SP1 installed on the 64-bit install,
but it isn't installed on the 32-bit install. However, when I run the
x86 SP1, it doesn't find that I have Reporting Services installed, so
it doesn't update it. I've run the 32-bit and the 64-bit SP1 installer
several times (with reboots!), but to no avail.
Any suggestions? I think I need the SP1 installer to find my
installation of the 32-bit Reporting Services.
Thanks,
CliffeA little more info: If I try to run the 32-bit setup from the original
install CD, it doesn't recognize that anything's installed - it walks
through the wizard from scratch.
If I run ARPWrapper.exe from \Program Files (x86)\Microsoft SQL
Server\90\Setup Bootstrap, it comes up with an error "SQL Server Setup
cannot proceed because the component you have selected has already been
uninstalled. Refer to books online..."
Any suggestions?
Thanks,
Cliffe
cliffeh wrote:
> I have a SQL Server 2005 install with the 64-bit Database Server, but
> I've had to install the 32-bit version of Reporting Services, since IIS
> is running in 32-bit mode. Everything's green in the Configuration
> Tool, but when I go to http://server/reportserver, I get the following
> error:
> The version of the report server database is either in a format that is
> not valid, or it cannot be read. The found version is 'C.0.8.43'. The
> expected version is 'C.0.8.40'. To continue, update the version of the
> report server database and verify access rights.
> (rsInvalidReportServerDatabase)
> I think the problem is that I have SP1 installed on the 64-bit install,
> but it isn't installed on the 32-bit install. However, when I run the
> x86 SP1, it doesn't find that I have Reporting Services installed, so
> it doesn't update it. I've run the 32-bit and the 64-bit SP1 installer
> several times (with reboots!), but to no avail.
> Any suggestions? I think I need the SP1 installer to find my
> installation of the 32-bit Reporting Services.
> Thanks,
> Cliffe
I've had to install the 32-bit version of Reporting Services, since IIS
is running in 32-bit mode. Everything's green in the Configuration
Tool, but when I go to http://server/reportserver, I get the following
error:
The version of the report server database is either in a format that is
not valid, or it cannot be read. The found version is 'C.0.8.43'. The
expected version is 'C.0.8.40'. To continue, update the version of the
report server database and verify access rights.
(rsInvalidReportServerDatabase)
I think the problem is that I have SP1 installed on the 64-bit install,
but it isn't installed on the 32-bit install. However, when I run the
x86 SP1, it doesn't find that I have Reporting Services installed, so
it doesn't update it. I've run the 32-bit and the 64-bit SP1 installer
several times (with reboots!), but to no avail.
Any suggestions? I think I need the SP1 installer to find my
installation of the 32-bit Reporting Services.
Thanks,
CliffeA little more info: If I try to run the 32-bit setup from the original
install CD, it doesn't recognize that anything's installed - it walks
through the wizard from scratch.
If I run ARPWrapper.exe from \Program Files (x86)\Microsoft SQL
Server\90\Setup Bootstrap, it comes up with an error "SQL Server Setup
cannot proceed because the component you have selected has already been
uninstalled. Refer to books online..."
Any suggestions?
Thanks,
Cliffe
cliffeh wrote:
> I have a SQL Server 2005 install with the 64-bit Database Server, but
> I've had to install the 32-bit version of Reporting Services, since IIS
> is running in 32-bit mode. Everything's green in the Configuration
> Tool, but when I go to http://server/reportserver, I get the following
> error:
> The version of the report server database is either in a format that is
> not valid, or it cannot be read. The found version is 'C.0.8.43'. The
> expected version is 'C.0.8.40'. To continue, update the version of the
> report server database and verify access rights.
> (rsInvalidReportServerDatabase)
> I think the problem is that I have SP1 installed on the 64-bit install,
> but it isn't installed on the 32-bit install. However, when I run the
> x86 SP1, it doesn't find that I have Reporting Services installed, so
> it doesn't update it. I've run the 32-bit and the 64-bit SP1 installer
> several times (with reboots!), but to no avail.
> Any suggestions? I think I need the SP1 installer to find my
> installation of the 32-bit Reporting Services.
> Thanks,
> Cliffe
Subscribe to:
Posts (Atom)