Normalisation vs If it works just do it!

Hi All,

As an accomplished web devver of many years using ASP and ASP.NET in conjunction with Access and SQL Server, I am a bit pedantic on the rules of good data structures.

Specifically the two main rules of data redundancy and normalisation.

The latter dictates at the lowest level that a data table should NOT contain a field that can be gleaned from one or a combination of others.

I have a problem with this now, I am building a betting system which will take the odds given, plus the stake placed and calculate the winnings or losses accordingly.

There is an added complication in that not all profit is calculated the same way, as a horse can also be 'placed' which does the same calculation as for profit, but then quarters it, so one single select statement won't do.

I could calculate this at data entry stage on a per entry basis and simply store in a Profit/Loss field and keep the value for each bet, however I know this is not the correct thing to do!

My other alternative [and the correct method] is to do this calculation at data request time, but that would involve the use of a cursor or loop in the SP.

I am aware of the huge resources a cursor can consume and I am not sure which is worse, using a cursor or ignoring the normalisation procedures.

So the question is this, what would you do here?

Since I may not be the same SQL Server expert as I am a programmer, is there an alternative way of reading all the bets and doing these calcs on SQL server and bang them back to ASP as a self contained recordset with all the profit/losses calculated for each bet?

Each bet as a unique EntryID and there is a field called Result which stores 'Win, Place or Loss' accordingly.

Thanks in advance of any help/opinions.

:)I'm a bit confused... When I use the term "place" to describe a horse racing bet, I mean that I expect (and am wagering that) the horse will finish second. While it is unusual to do, you can "box" a single horse, meaning that you expect them to place in the top 3, but you retrieve your original wager plus twenty percent of what the return would have been for a correct bet (win, place, or show), which sounds something like your description of a "place" bet.

If you can describe what you really want, I'm sure that someone here on the forum can show you how to code it!

-PatP|||Hi,

Thanks for the response, the actual calculations is not the issue e.g. the odds for a place bet, that is already known.

The problem concerns how to read through the table of placed bets while calculating the profit/loss as we iterate through each record.

The arithmetic is not the issue here, its the method of retrieval so that each record will have a field containing a profit or loss amount, put there by SQL as it reads through each item.

Thanks.|||Performance is the key in my work. If running the cursor is going to slow down the operation then having a little redundency isn't bad.|||My thought would be to do an UPDATE using the CASE to control which computation you use (main or place). Clean, fast, no cursor... What more could you ask?

-PatP

Noob question about SQL Server Express used local and on server.

I have just started looking at using a database with my web site. If I have SQL Server Express with the Advanced Services on my local machine and I use it to make interactive pages, can I use the schema and tables on the actual web site on a remote server? If so does that server need to have SQL Server Express installed too?

A link to a tutorial or reference that goes into some detail would be awsome!

Thanks everyone!

Yes, you will need SQL Express and the Advanced Services installed on the server. Depending on how you have it setup, you should just be able to copy the contents of th App_Data folder over and it should work. This page should provide further information:http://msdn2.microsoft.com/en-us/library/ms165668.aspx

Non-default IIS Web site

Hi,
Can I install reporting service to non-default IIS Web site?
If Yes, How?
Thanks.
SaraNope.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Sara" <Sara@.discussions.microsoft.com> wrote in message
news:6D63FBB0-77A0-4042-9392-25CA9FF9AAE5@.microsoft.com...
> Hi,
> Can I install reporting service to non-default IIS Web site?
> If Yes, How?
> Thanks.
> Sara|||I should add that you might be able to do this with SQL 2005, if the
standalone reporting options work as I understand them being described.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Jeff A. Stucker" <jeff@.mobilize.net> wrote in message
news:O0%23uyZP9EHA.3260@.TK2MSFTNGP14.phx.gbl...
> Nope.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "Sara" <Sara@.discussions.microsoft.com> wrote in message
> news:6D63FBB0-77A0-4042-9392-25CA9FF9AAE5@.microsoft.com...
>> Hi,
>> Can I install reporting service to non-default IIS Web site?
>> If Yes, How?
>> Thanks.
>> Sara
>|||This is a multi-part message in MIME format.
--=_NextPart_000_0018_01C4F4D3.BC870AA0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
I don't think you can but I have been wrong before...
What we do instead is enable Default Web, install RS to it, then move =them to our other site. One thing to watch out for (on Windows Server =2003) is ensuring that you add the aspnet_isapi library for =ReportServer. We spent a few days looking at everything but that at one =point in time...
-- TIM ELLISON
"Sara" <Sara@.discussions.microsoft.com> wrote in message =news:6D63FBB0-77A0-4042-9392-25CA9FF9AAE5@.microsoft.com...
Hi,
Can I install reporting service to non-default IIS Web site?
If Yes, How?
Thanks.
Sara
--=_NextPart_000_0018_01C4F4D3.BC870AA0
Content-Type: text/html;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

---

I don't think you can but I have been =wrong before...
What we do instead is enable Default =Web, install RS to it, then move them to our other site. One thing to watch out =for (on Windows Server 2003) is ensuring that you add the aspnet_isapi library =for ReportServer. We spent a few days looking at everything but that =at one point in time...
-- TIM ELLISON
"Sara" wrote in message news:6D6=3FBB0-77A0-4042-9392-25CA9FF9AAE5@.microsoft.com...Hi,Ca=n I install reporting service to non-default IIS Web site?If Yes, How?Thanks.Sara

---

--=_NextPart_000_0018_01C4F4D3.BC870AA0--|||This is a multi-part message in MIME format.
--=_NextPart_000_005E_01C4F7F9.C4BF5F50
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
You can do that easily. Try to look at this site, they explain how to =move reporting services' Virtual directory very well. =http://www.sqljunkies.com/HowTo/525B575A-7F61-483A-AC8F-FEC700C34674.scuk=
good Luck!!
"Tim Ellison" <TimEllison@.direcway.com> a =C3=A9crit dans le message =de news:OZHlm2P9EHA.2196@.TK2MSFTNGP11.phx.gbl...
I don't think you can but I have been wrong before...
What we do instead is enable Default Web, install RS to it, then move =them to our other site. One thing to watch out for (on Windows Server =2003) is ensuring that you add the aspnet_isapi library for =ReportServer. We spent a few days looking at everything but that at one =point in time...
-- TIM ELLISON
"Sara" <Sara@.discussions.microsoft.com> wrote in message =news:6D63FBB0-77A0-4042-9392-25CA9FF9AAE5@.microsoft.com...
Hi,
Can I install reporting service to non-default IIS Web site?
If Yes, How?
Thanks.
Sara
--=_NextPart_000_005E_01C4F7F9.C4BF5F50
Content-Type: text/html;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

---

You can do that easily. Try to look at this site, they explain how to move reporting services' =Virtual directory very well. http://www.sqljunkies.com/HowTo/525B575A-7F61-483A-AC8F-FEC700C=34674.scuk
good Luck!!
"Tim Ellison" =a =C3=A9crit dans le message de news:OZHlm2P9EHA.2196=@.TK2MSFTNGP11.phx.gbl...
I don't think you can but I have been =wrong before...

What we do instead is enable Default =Web, install RS to it, then move them to our other site. One thing to watch =out for (on Windows Server 2003) is ensuring that you add the aspnet_isapi =library for ReportServer. We spent a few days looking at everything but that =at one point in time...
-- TIM ELLISON
"Sara" wrote in message news:6D6=3FBB0-77A0-4042-9392-25CA9FF9AAE5@.microsoft.com...Hi,Ca=n I install reporting service to non-default IIS Web site?If Yes, =How?Thanks.Sara

---

--=_NextPart_000_005E_01C4F7F9.C4BF5F50--

Non English Characters

Hi,
We are developing a small web interface to a local ERP software, which
uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
collation, and the fields are varchar (not nvarchar), however, the main
program inserts and reads non-English (Turkish) characters into these
columns. However, when we connect to database with ADO.NET, these
characters are not read correctly. (The situation is same when I check
tables with Enterprise Manager and Query Analyzer)

In a past situation (which was about a Win32 application), I have heard
about character conversion behaviour of ADO (and many other DB
libraries) and solved that problem using BDE instead of ADO, so that
the connection is made via DB-Library instead of OLEDB.

But this way cannot be applied to my ASP.NET situation, and there is NO
way to change database collation. Must I use a ADO.NET property, or use
another provider, or maybe another library? Any advices? Thanks...Set your culture settings in your web.config file for the appropriate code
set that you use. This should solve the problem. You can also cast the
characters to ASCII by doing this (courtesy or Erland Sommerskog)

SELECT convert(varchar(6), N'IGDEM' COLLATE Cyrillic_General_CS_AS)

--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.

This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.

Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<saygin@.gmail.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

Hi,
We are developing a small web interface to a local ERP software, which
uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
collation, and the fields are varchar (not nvarchar), however, the main
program inserts and reads non-English (Turkish) characters into these
columns. However, when we connect to database with ADO.NET, these
characters are not read correctly. (The situation is same when I check
tables with Enterprise Manager and Query Analyzer)
>
In a past situation (which was about a Win32 application), I have heard
about character conversion behaviour of ADO (and many other DB
libraries) and solved that problem using BDE instead of ADO, so that
the connection is made via DB-Library instead of OLEDB.
>
But this way cannot be applied to my ASP.NET situation, and there is NO
way to change database collation. Must I use a ADO.NET property, or use
another provider, or maybe another library? Any advices? Thanks...
>

|||A couple more thoughts are you storing the strings in nVarchar(20) data type
columns. Also if you use Erland's method you will loose the Turkish
characters if you store them using his technique but the searching should
work.

--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.

This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.

Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<saygin@.gmail.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

Hi,
We are developing a small web interface to a local ERP software, which
uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
collation, and the fields are varchar (not nvarchar), however, the main
program inserts and reads non-English (Turkish) characters into these
columns. However, when we connect to database with ADO.NET, these
characters are not read correctly. (The situation is same when I check
tables with Enterprise Manager and Query Analyzer)
>
In a past situation (which was about a Win32 application), I have heard
about character conversion behaviour of ADO (and many other DB
libraries) and solved that problem using BDE instead of ADO, so that
the connection is made via DB-Library instead of OLEDB.
>
But this way cannot be applied to my ASP.NET situation, and there is NO
way to change database collation. Must I use a ADO.NET property, or use
another provider, or maybe another library? Any advices? Thanks...
>

|||Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also :) However I cannot find a similar solution for
ASP.NET

Hilary Cotter wrote:

Quote:

Originally Posted by

A couple more thoughts are you storing the strings in nVarchar(20) data type
columns. Also if you use Erland's method you will loose the Turkish
characters if you store them using his technique but the searching should
work.
>
--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
>
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
>
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
>
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
>
>
>
<saygin@.gmail.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

Hi,
We are developing a small web interface to a local ERP software, which
uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
collation, and the fields are varchar (not nvarchar), however, the main
program inserts and reads non-English (Turkish) characters into these
columns. However, when we connect to database with ADO.NET, these
characters are not read correctly. (The situation is same when I check
tables with Enterprise Manager and Query Analyzer)

In a past situation (which was about a Win32 application), I have heard
about character conversion behaviour of ADO (and many other DB
libraries) and solved that problem using BDE instead of ADO, so that
the connection is made via DB-Library instead of OLEDB.

But this way cannot be applied to my ASP.NET situation, and there is NO
way to change database collation. Must I use a ADO.NET property, or use
another provider, or maybe another library? Any advices? Thanks...

|||Hi,
Choosing ODBC provider rather than OLEDB, and turning of character
translation option solved my problem.

saygin@.gmail.com wrote:

Quote:

Originally Posted by

Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also :) However I cannot find a similar solution for
ASP.NET
>
>
>
>
Hilary Cotter wrote:

Quote:

Originally Posted by

A couple more thoughts are you storing the strings in nVarchar(20) data type
columns. Also if you use Erland's method you will loose the Turkish
characters if you store them using his technique but the searching should
work.

--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.

This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.

Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<saygin@.gmail.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

Hi,
We are developing a small web interface to a local ERP software, which
uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
collation, and the fields are varchar (not nvarchar), however, the main
program inserts and reads non-English (Turkish) characters into these
columns. However, when we connect to database with ADO.NET, these
characters are not read correctly. (The situation is same when I check
tables with Enterprise Manager and Query Analyzer)
>
In a past situation (which was about a Win32 application), I have heard
about character conversion behaviour of ADO (and many other DB
libraries) and solved that problem using BDE instead of ADO, so that
the connection is made via DB-Library instead of OLEDB.
>
But this way cannot be applied to my ASP.NET situation, and there is NO
way to change database collation. Must I use a ADO.NET property, or use
another provider, or maybe another library? Any advices? Thanks...
>

Non English Characters

Hi,
We are developing a small web interface to a local ERP software, which
uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
collation, and the fields are varchar (not nvarchar), however, the main
program inserts and reads non-English (Turkish) characters into these
columns. However, when we connect to database with ADO.NET, these
characters are not read correctly. (The situation is same when I check
tables with Enterprise Manager and Query Analyzer)
In a past situation (which was about a Win32 application), I have heard
about character conversion behaviour of ADO (and many other DB
libraries) and solved that problem using BDE instead of ADO, so that
the connection is made via DB-Library instead of OLEDB.
But this way cannot be applied to my ASP.NET situation, and there is NO
way to change database collation. Must I use a ADO.NET property, or use
another provider, or maybe another library? Any advices? Thanks...
Set your culture settings in your web.config file for the appropriate code
set that you use. This should solve the problem. You can also cast the
characters to ASCII by doing this (courtesy or Erland Sommerskog)
SELECT convert(varchar(6), N'IGDEM' COLLATE Cyrillic_General_CS_AS)
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<saygin@.gmail.com> wrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...
> Hi,
> We are developing a small web interface to a local ERP software, which
> uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
> collation, and the fields are varchar (not nvarchar), however, the main
> program inserts and reads non-English (Turkish) characters into these
> columns. However, when we connect to database with ADO.NET, these
> characters are not read correctly. (The situation is same when I check
> tables with Enterprise Manager and Query Analyzer)
> In a past situation (which was about a Win32 application), I have heard
> about character conversion behaviour of ADO (and many other DB
> libraries) and solved that problem using BDE instead of ADO, so that
> the connection is made via DB-Library instead of OLEDB.
> But this way cannot be applied to my ASP.NET situation, and there is NO
> way to change database collation. Must I use a ADO.NET property, or use
> another provider, or maybe another library? Any advices? Thanks...
>
|||A couple more thoughts are you storing the strings in nVarchar(20) data type
columns. Also if you use Erland's method you will loose the Turkish
characters if you store them using his technique but the searching should
work.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<saygin@.gmail.com> wrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...
> Hi,
> We are developing a small web interface to a local ERP software, which
> uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
> collation, and the fields are varchar (not nvarchar), however, the main
> program inserts and reads non-English (Turkish) characters into these
> columns. However, when we connect to database with ADO.NET, these
> characters are not read correctly. (The situation is same when I check
> tables with Enterprise Manager and Query Analyzer)
> In a past situation (which was about a Win32 application), I have heard
> about character conversion behaviour of ADO (and many other DB
> libraries) and solved that problem using BDE instead of ADO, so that
> the connection is made via DB-Library instead of OLEDB.
> But this way cannot be applied to my ASP.NET situation, and there is NO
> way to change database collation. Must I use a ADO.NET property, or use
> another provider, or maybe another library? Any advices? Thanks...
>
|||Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also However I cannot find a similar solution for
ASP.NET
Hilary Cotter wrote:[vbcol=seagreen]
> A couple more thoughts are you storing the strings in nVarchar(20) data type
> columns. Also if you use Erland's method you will loose the Turkish
> characters if you store them using his technique but the searching should
> work.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> <saygin@.gmail.com> wrote in message
> news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...
|||Hi,
Choosing ODBC provider rather than OLEDB, and turning of character
translation option solved my problem.
saygin@.gmail.com wrote:[vbcol=seagreen]
> Hi, thanks for your interest.
> Changing culture setting did not help, also there is no chance to
> change data type of columns, they are varchar, not nvarchar.
> Character conversion of database libraries and using a DB-Library based
> API (in my previous example I'd chosen BDE) was Mr.Erland's
> recommendation also However I cannot find a similar solution for
> ASP.NET
>
>
> Hilary Cotter wrote:

Non English Characters

Hi,
We are developing a small web interface to a local ERP software, which
uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
collation, and the fields are varchar (not nvarchar), however, the main
program inserts and reads non-English (Turkish) characters into these
columns. However, when we connect to database with ADO.NET, these
characters are not read correctly. (The situation is same when I check
tables with Enterprise Manager and Query Analyzer)
In a past situation (which was about a Win32 application), I have heard
about character conversion behaviour of ADO (and many other DB
libraries) and solved that problem using BDE instead of ADO, so that
the connection is made via DB-Library instead of OLEDB.
But this way cannot be applied to my ASP.NET situation, and there is NO
way to change database collation. Must I use a ADO.NET property, or use
another provider, or maybe another library? Any advices? Thanks...Set your culture settings in your web.config file for the appropriate code
set that you use. This should solve the problem. You can also cast the
characters to ASCII by doing this (courtesy or Erland Sommerskog)
SELECT convert(varchar(6), N'IGDEM' COLLATE Cyrillic_General_CS_AS)
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<saygin@.gmail.com> wrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegroups.com...
> Hi,
> We are developing a small web interface to a local ERP software, which
> uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
> collation, and the fields are varchar (not nvarchar), however, the main
> program inserts and reads non-English (Turkish) characters into these
> columns. However, when we connect to database with ADO.NET, these
> characters are not read correctly. (The situation is same when I check
> tables with Enterprise Manager and Query Analyzer)
> In a past situation (which was about a Win32 application), I have heard
> about character conversion behaviour of ADO (and many other DB
> libraries) and solved that problem using BDE instead of ADO, so that
> the connection is made via DB-Library instead of OLEDB.
> But this way cannot be applied to my ASP.NET situation, and there is NO
> way to change database collation. Must I use a ADO.NET property, or use
> another provider, or maybe another library? Any advices? Thanks...
>|||A couple more thoughts are you storing the strings in nVarchar(20) data type
columns. Also if you use Erland's method you will loose the Turkish
characters if you store them using his technique but the searching should
work.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<saygin@.gmail.com> wrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegroups.com...
> Hi,
> We are developing a small web interface to a local ERP software, which
> uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
> collation, and the fields are varchar (not nvarchar), however, the main
> program inserts and reads non-English (Turkish) characters into these
> columns. However, when we connect to database with ADO.NET, these
> characters are not read correctly. (The situation is same when I check
> tables with Enterprise Manager and Query Analyzer)
> In a past situation (which was about a Win32 application), I have heard
> about character conversion behaviour of ADO (and many other DB
> libraries) and solved that problem using BDE instead of ADO, so that
> the connection is made via DB-Library instead of OLEDB.
> But this way cannot be applied to my ASP.NET situation, and there is NO
> way to change database collation. Must I use a ADO.NET property, or use
> another provider, or maybe another library? Any advices? Thanks...
>|||Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also However I cannot find a similar solution for
ASP.NET
Hilary Cotter wrote:[vbcol=seagreen]
> A couple more thoughts are you storing the strings in nVarchar(20) data ty
pe
> columns. Also if you use Erland's method you will loose the Turkish
> characters if you store them using his technique but the searching should
> work.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> <saygin@.gmail.com> wrote in message
> news:1159361639.289293.15470@.d34g2000cwd.googlegroups.com...|||Hi,
Choosing ODBC provider rather than OLEDB, and turning of character
translation option solved my problem.
saygin@.gmail.com wrote:[vbcol=seagreen]
> Hi, thanks for your interest.
> Changing culture setting did not help, also there is no chance to
> change data type of columns, they are varchar, not nvarchar.
> Character conversion of database libraries and using a DB-Library based
> API (in my previous example I'd chosen BDE) was Mr.Erland's
> recommendation also However I cannot find a similar solution for
> ASP.NET
>
>
> Hilary Cotter wrote:

No Views in SQL Web Data Administrator

Does anyone know how I can access Views in the SQL Web Data Administrator? All I can see is Tables, Stored Procedures, Query, Properties, Users, Roles.Hi,
I guess its by design.No UDF's too :-(
--
Dinesh
SQL Server MVP
--
--
SQL Server FAQ at
http://www.tkdinesh.com
"Checkbox" <Checkbox@.discussions.microsoft.com> wrote in message
news:48BE1D32-E933-4807-B37B-38FD280017D3@.microsoft.com...
> Does anyone know how I can access Views in the SQL Web Data Administrator?
All I can see is Tables, Stored Procedures, Query, Properties, Users, Roles.
>

No Views in SQL Web Data Administrator

Does anyone know how I can access Views in the SQL Web Data Administrator?
All I can see is Tables, Stored Procedures, Query, Properties, Users, Roles.Hi,
I guess its by design.No UDF's too :-(
Dinesh
SQL Server MVP
--
--
SQL Server FAQ at
http://www.tkdinesh.com
"Checkbox" <Checkbox@.discussions.microsoft.com> wrote in message
news:48BE1D32-E933-4807-B37B-38FD280017D3@.microsoft.com...
> Does anyone know how I can access Views in the SQL Web Data Administrator?
All I can see is Tables, Stored Procedures, Query, Properties, Users, Roles.
>

No Views in SQL Web Data Administrator

Does anyone know how I can access Views in the SQL Web Data Administrator? All I can see is Tables, Stored Procedures, Query, Properties, Users, Roles.
Hi,
I guess its by design.No UDF's too :-(
Dinesh
SQL Server MVP
--
SQL Server FAQ at
http://www.tkdinesh.com
"Checkbox" <Checkbox@.discussions.microsoft.com> wrote in message
news:48BE1D32-E933-4807-B37B-38FD280017D3@.microsoft.com...
> Does anyone know how I can access Views in the SQL Web Data Administrator?
All I can see is Tables, Stored Procedures, Query, Properties, Users, Roles.
>

No SRC in IMG tag in HTML Fragment

I am using the web service render command to pull out the HTML fragment to
display on a page but the SRC attribute of the IMG tags are all blank. I
know the image is available in the RenderStream but how do I link the two
together?
Is this just an HTML problem? If so where should I look?
Thanks in advance.
StevenThe location of the images can be specified via the StreamRoot device info.
However, the SRC tags should not be blank.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Steven Lawrence" <steven@.metagenerics.co.za> wrote in message
news:O6QzEywaEHA.3012@.tk2msftngp13.phx.gbl...
>I am using the web service render command to pull out the HTML fragment to
> display on a page but the SRC attribute of the IMG tags are all blank. I
> know the image is available in the RenderStream but how do I link the two
> together?
> Is this just an HTML problem? If so where should I look?
> Thanks in advance.
> Steven
>
>