473,322 Members | 1,307 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

SQL Server 2005 and file systems, any recommendations

We're planning to migrate our db to new and more disk drives, faster
RAID levels and more dedicated disk usage(e.g. placing the translog on
dedicated disks). The db server runs on Win2003.

Right now we're thinking about what file system to use on the new
drives. We opt for performance, but expect reliability as well.(Goes
without saying, IMHO ;-))
>From what I can tell, NTFS is a journaling file system, at least it
does some journaling. I'd prefer to have no journaling and sacrifice
boot time for performance, and was wondering if it either is possible
to turn journaling off in NTFS or at least move the journal to a
separate disk. Is it doable, has anyone done this and are there any
benefits? Any downside?

Are there any commonly recommended tweaks to NTFS when the server and
disk is dedicated to SQL Server? Stuff like
NTFSDisableLastAccessUpdate.

How about alternatives to to NTFS? Is FAT32 viable or do we need to
look at Veritas or others?

TIA for all comments.

Bjørn Augestad

Aug 3 '06 #1
18 4747
bj************@gmail.com (bj************@gmail.com) writes:
We're planning to migrate our db to new and more disk drives, faster
RAID levels and more dedicated disk usage(e.g. placing the translog on
dedicated disks). The db server runs on Win2003.

Right now we're thinking about what file system to use on the new
drives. We opt for performance, but expect reliability as well.(Goes
without saying, IMHO ;-))
>>From what I can tell, NTFS is a journaling file system, at least it
does some journaling. I'd prefer to have no journaling and sacrifice
boot time for performance, and was wondering if it either is possible
to turn journaling off in NTFS or at least move the journal to a
separate disk. Is it doable, has anyone done this and are there any
benefits? Any downside?

Are there any commonly recommended tweaks to NTFS when the server and
disk is dedicated to SQL Server? Stuff like
NTFSDisableLastAccessUpdate.

How about alternatives to to NTFS? Is FAT32 viable or do we need to
look at Veritas or others?
No, FAT32 is not a very good alternative. There are several features in
SQL Server that are not available with FAT32. I got this list from one
of the SQL Server developers:

1. Database snapshots - require support for sparse files which is available
only under NTFS
2. DBCC snapshot usage - requires support for alternate streams which is
available only under NTFS
3. Mount points under cluster
4. Data file compression which uses NTFS compression
5. Encryption of database files is supported only under NTFS
6. Differential backup, restore of full-text catalog files is supported only
under NTFS

He says the list may not be complete. He also added "I believe that recovery
mechanisms are more robust under NTFS and protects against system failures.
I think the user is worrying too much about NTFS when there are other
obvious performance bottlenecks."
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
Aug 4 '06 #2
Erland Sommarskog wrote:
bj************@gmail.com (bj************@gmail.com) writes:
We're planning to migrate our db to new and more disk drives, faster
RAID levels and more dedicated disk usage(e.g. placing the translog on
dedicated disks). The db server runs on Win2003.

Right now we're thinking about what file system to use on the new
drives. We opt for performance, but expect reliability as well.(Goes
without saying, IMHO ;-))
>From what I can tell, NTFS is a journaling file system, at least it
does some journaling. I'd prefer to have no journaling and sacrifice
boot time for performance, and was wondering if it either is possible
to turn journaling off in NTFS or at least move the journal to a
separate disk. Is it doable, has anyone done this and are there any
benefits? Any downside?

Are there any commonly recommended tweaks to NTFS when the server and
disk is dedicated to SQL Server? Stuff like
NTFSDisableLastAccessUpdate.

How about alternatives to to NTFS? Is FAT32 viable or do we need to
look at Veritas or others?

No, FAT32 is not a very good alternative. There are several features in
SQL Server that are not available with FAT32. I got this list from one
of the SQL Server developers:

1. Database snapshots - require support for sparse files which is available
only under NTFS
2. DBCC snapshot usage - requires support for alternate streams which is
available only under NTFS
3. Mount points under cluster
4. Data file compression which uses NTFS compression
5. Encryption of database files is supported only under NTFS
6. Differential backup, restore of full-text catalog files is supported only
under NTFS

He says the list may not be complete. He also added "I believe that recovery
mechanisms are more robust under NTFS and protects against system failures.
I think the user is worrying too much about NTFS when there are other
obvious performance bottlenecks."
I get your point(s) :-) So FAT32 is out, not a big surprise.

Once upon a time I was playing around with file systems(JFS, XFS and
others), Oracle and AIX as well as OSF/1. I spent a considerable time
measuring performance for different configurations and journaling file
systems *with* the journal on the same disk as the db data(or translog)
was awfully slow compared to other configurations. I assumed that is
was due to disk head movements back and forth between the journal and
the file.

So even if the file system isn't the performance bottleneck right now,
I'd prefer to configure all the new disk drives optimally from day one.
I read the NTFS spec and browsed through all the options, but couldn't
find anything about tuning the journal. I'll have to reread it, I
guess...

Thanks,
Bjørn

Aug 5 '06 #3
>I get your point(s) :-) So FAT32 is out, not a big surprise.
>
Once upon a time I was playing around with file systems(JFS, XFS and
others), Oracle and AIX as well as OSF/1. I spent a considerable time
measuring performance for different configurations and journaling file
systems *with* the journal on the same disk as the db data(or translog)
was awfully slow compared to other configurations. I assumed that is
was due to disk head movements back and forth between the journal and
the file.

So even if the file system isn't the performance bottleneck right now,
I'd prefer to configure all the new disk drives optimally from day one.
I read the NTFS spec and browsed through all the options, but couldn't
find anything about tuning the journal. I'll have to reread it, I
guess...
There is the option of raw partition. A fellow MVP told me that he
made some tests some years back (so it was not on SQL 2005), and got
a 20% improvement with raw partition. But raw partitions are difficult
to manage, and I guess that you would still have to use NTFS for things
like database snapshots. Personally, I would never consider using raw
partition for a production system.

20% may sound significant, but there other ways to get a 20% speedup,
for instance by sticking to a binary collation, or using an SQL
collation for varchar data. In fact, for a query like.

SELECT ... FROM tbl WHER col LIKE '%Whatever%'

the difference between a CI/CS collation and a binary collation can be
factor seven.

You also lose 90% in performance by writing a bad query.

You may be interested in this article:
http://www.microsoft.com/technet/pro...hysdbstor.mspx.

--
Erland Sommarskog, Stockholm, es****@sommarskog.se

Aug 5 '06 #4
Erland Sommarskog wrote:
>>I get your point(s) :-) So FAT32 is out, not a big surprise.

Once upon a time I was playing around with file systems(JFS, XFS and
others), Oracle and AIX as well as OSF/1. I spent a considerable time
measuring performance for different configurations and journaling file
systems *with* the journal on the same disk as the db data(or translog)
was awfully slow compared to other configurations. I assumed that is
was due to disk head movements back and forth between the journal and
the file.

So even if the file system isn't the performance bottleneck right now,
I'd prefer to configure all the new disk drives optimally from day one.
I read the NTFS spec and browsed through all the options, but couldn't
find anything about tuning the journal. I'll have to reread it, I
guess...


There is the option of raw partition. A fellow MVP told me that he
made some tests some years back (so it was not on SQL 2005), and got
a 20% improvement with raw partition. But raw partitions are difficult
to manage, and I guess that you would still have to use NTFS for things
like database snapshots. Personally, I would never consider using raw
partition for a production system.
I thought that support for raw partitions was dropped? Even if it still
exists, I won't use it for data, maybe for a transaction log safely
placed on a tiny slice of a 15K RAID-1 disk. I hope I'll find the time
to test and measure the performance for such a setup. Nice just to know,
even if it can be a pita to find the proper statement mix to test with.

The best solution, IMHO, would be to have NTFS without journaling or
NTFS with the journal on a separate disk. If that's not possible, we'll
probably just settle for regular NTFS partitions, or maybe throw in a
couple of RamSan-400 boxes ;-)
>
20% may sound significant, but there other ways to get a 20% speedup,
for instance by sticking to a binary collation,
What about proper sorting of our æøå's and other funny european
characters? Won't work, will it?
or using an SQL
collation for varchar data. In fact, for a query like.

SELECT ... FROM tbl WHER col LIKE '%Whatever%'

the difference between a CI/CS collation and a binary collation can be
factor seven.

You also lose 90% in performance by writing a bad query.
That I've noticed. Lots of 'silly' gotchas to remember and beware of.
BTW, I did som more profiling today on one of the production servers,
expected everything to be quiet as it is sunday. Quite a surprise to
find that it was performing 662 calls to sp_reset_connection per second
over a period of 45 minutes. As you may have guessed, the system has
'issues'...
>
You may be interested in this article:
http://www.microsoft.com/technet/pro...hysdbstor.mspx.
Thanks, I'll read it asap.

Another thing: Have you got any links to a site describing proper use of
SARGs and operators and the query optimizer? I threw away my copy of SQL
Server Unleashed (never do that) and have forgotten all about it. The
Unleashed for 2005 won't we available until Nov. 27th...

Bjørn
Aug 6 '06 #5
Bjørn Augestad (bj************@gmail.com) writes:
Erland Sommarskog wrote:
>20% may sound significant, but there other ways to get a 20% speedup,
for instance by sticking to a binary collation,

What about proper sorting of our æøå's and other funny european
characters? Won't work, will it?
Correct. A binary collation comes with a price. So does raw partitions.
Another thing: Have you got any links to a site describing proper use of
SARGs and operators and the query optimizer? I threw away my copy of SQL
Server Unleashed (never do that) and have forgotten all about it. The
Unleashed for 2005 won't we available until Nov. 27th...
No direct link, but the obvious place to look around would be
http://www.sql-server-performance.com/
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
Aug 6 '06 #6
Bjørn Augestad wrote:
The best solution, IMHO, would be to have NTFS without journaling or
NTFS with the journal on a separate disk. If that's not possible, we'll
probably just settle for regular NTFS partitions, or maybe throw in a
couple of RamSan-400 boxes ;-)
I'm by no means an expert on NTFS but as far as I can determine
journaling applies only to file allocation, not to data. In a
well-managed environment SQL Server's storage should generally be
pre-allocated so I don't see why journaling should need to be a
performance constraint at runtime.

Maybe I've missed something but I have actually never heard anyone
raise a concern about this before and I've found virtually no relevant
information on it. That suggests to me that it's not an issue I need to
be concerned about. My impression is the same as Erland's: other
factors must rate as far more important determinants of DBMS
performance.

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/m...S,SQL.90).aspx
--

Aug 6 '06 #7
Erland Sommarskog wrote:
Bjørn Augestad (bj************@gmail.com) writes:
>Erland Sommarskog wrote:
>>20% may sound significant, but there other ways to get a 20% speedup,
for instance by sticking to a binary collation,
What about proper sorting of our æøå's and other funny european
characters? Won't work, will it?

Correct. A binary collation comes with a price. So does raw partitions.
Would you please explain what you intend with this comment about block
devices. With any database, other apparently than Microsoft's, there is
an advantage that accrues to those who forgo file systems. Why is SQL
Server different?

Thanks.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Aug 7 '06 #8
DA Morgan (da******@psoug.org) writes:
Erland Sommarskog wrote:
>Correct. A binary collation comes with a price. So does raw partitions.

Would you please explain what you intend with this comment about block
devices. With any database, other apparently than Microsoft's, there is
an advantage that accrues to those who forgo file systems. Why is SQL
Server different?
I referred previously in the thread to a fellow MVP who had found a 20%
improvement with raw devices over the file system.

The price I'm talking about is the more complex administration that raw
devices buy you.

As for why they are complex... Many years ago when I worked with Sybase,
I had to travel to customer to perform a triple upgrade: upgrade HP-UX
from 8.0 to 9.0, Sybase from 4.2 to 4.9 and our own application. The
customer had adequate staff to run the OS upgrade themselves, but still
they wanted us to it. The reason: in this OS upgrade HP-UX introduced
logical volumes, having had only fixed partitions before, and the customer
did not know how to handle Sybase, where all data was on raw partitions.
Had the databases been on plain files, the OS upgrade would have been
trivial for them. But in those days, Sybase strongly discouraged you from
running production databases on file-system devices, and with a good reason,
since buffering in the file system could cause problems.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
Aug 7 '06 #9
DA Morgan (da******@psoug.org) writes:
Erland Sommarskog wrote:
>Correct. A binary collation comes with a price. So does raw partitions.

Would you please explain what you intend with this comment about block
devices. With any database, other apparently than Microsoft's, there is
an advantage that accrues to those who forgo file systems. Why is SQL
Server different?
It occurred to me that is another reason why SQL Server is different, which
is inherent in its architecture. Other engines have to support multiple
platforms and file systems, so they need to implement some abstract
interface to handle the file system. Using a raw device means that that
layer they can cirumventet.

Since SQL Server supports only Windows, it can be spared that layer of
abstraction, and thus the gain with raw devices is not equally compelling.

I like to stress that all this is pure speculation on my part.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
Aug 7 '06 #10
David Portas wrote:
Bjørn Augestad wrote:

>>The best solution, IMHO, would be to have NTFS without journaling or
NTFS with the journal on a separate disk. If that's not possible, we'll
probably just settle for regular NTFS partitions, or maybe throw in a
couple of RamSan-400 boxes ;-)


I'm by no means an expert on NTFS but as far as I can determine
journaling applies only to file allocation, not to data. In a
well-managed environment SQL Server's storage should generally be
pre-allocated so I don't see why journaling should need to be a
performance constraint at runtime.

I'm no NTFS expert either, so I read the tech spec for NTFS at
http://technet2.microsoft.com/Window....mspx?mfr=true

Here's a quote:
NTFS Change Journal

As files, folders, and other NTFS objects are added, deleted, and
modified, NTFS enters change journal records in streams, one for each
volume on the computer.

My interpretation, hopefully wrong, is that NTFS journal entries will be
written to disk whenever a file is modified. This will lead to disk head
movement and decreased performance on a busy disk, won't it?
>
Maybe I've missed something but I have actually never heard anyone
raise a concern about this before and I've found virtually no relevant
information on it. That suggests to me that it's not an issue I need to
be concerned about. My impression is the same as Erland's: other
factors must rate as far more important determinants of DBMS
performance.
I mostly agree, but it's nice to get the disk configuration correct from
day one as it is very hard to change it later. I didn't know if it is an
issue or not, that's why I wanted to check this.

Bjørn
>
--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/m...S,SQL.90).aspx
--
Aug 7 '06 #11
Erland Sommarskog wrote:
DA Morgan (da******@psoug.org) writes:
>Erland Sommarskog wrote:
>>Correct. A binary collation comes with a price. So does raw partitions.
Would you please explain what you intend with this comment about block
devices. With any database, other apparently than Microsoft's, there is
an advantage that accrues to those who forgo file systems. Why is SQL
Server different?

I referred previously in the thread to a fellow MVP who had found a 20%
improvement with raw devices over the file system.

The price I'm talking about is the more complex administration that raw
devices buy you.

As for why they are complex... Many years ago when I worked with Sybase,
I had to travel to customer to perform a triple upgrade: upgrade HP-UX
from 8.0 to 9.0, Sybase from 4.2 to 4.9 and our own application. The
customer had adequate staff to run the OS upgrade themselves, but still
they wanted us to it. The reason: in this OS upgrade HP-UX introduced
logical volumes, having had only fixed partitions before, and the customer
did not know how to handle Sybase, where all data was on raw partitions.
Had the databases been on plain files, the OS upgrade would have been
trivial for them. But in those days, Sybase strongly discouraged you from
running production databases on file-system devices, and with a good reason,
since buffering in the file system could cause problems.
Thanks. The "price" is well understood and there are a lot of good
solutions for simplifying block device administration: Just not with
SQL Server (for example AIX makes it very easy). Thanks.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Aug 7 '06 #12
Erland Sommarskog wrote:
DA Morgan (da******@psoug.org) writes:
>Erland Sommarskog wrote:
>>Correct. A binary collation comes with a price. So does raw partitions.
Would you please explain what you intend with this comment about block
devices. With any database, other apparently than Microsoft's, there is
an advantage that accrues to those who forgo file systems. Why is SQL
Server different?

It occurred to me that is another reason why SQL Server is different, which
is inherent in its architecture. Other engines have to support multiple
platforms and file systems, so they need to implement some abstract
interface to handle the file system. Using a raw device means that that
layer they can cirumventet.

Since SQL Server supports only Windows, it can be spared that layer of
abstraction, and thus the gain with raw devices is not equally compelling.

I like to stress that all this is pure speculation on my part.
Thanks.

I've seen this in other aspects as well. Being limited to a single
operating system, and one you control, moves many things from the
database to the operating system.

Of course if Vista shows up as a fattened pig ... that may not be such
a good thing. ;-) Again Thanks.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Aug 7 '06 #13
Bjørn Augestad wrote:
>

I'm no NTFS expert either, so I read the tech spec for NTFS at
http://technet2.microsoft.com/Window....mspx?mfr=true

Here's a quote:
NTFS Change Journal

As files, folders, and other NTFS objects are added, deleted, and
modified, NTFS enters change journal records in streams, one for each
volume on the computer.

My interpretation, hopefully wrong, is that NTFS journal entries will be
written to disk whenever a file is modified. This will lead to disk head
movement and decreased performance on a busy disk, won't it?

The point of NTFS journaling is to protect the integrity of file system
META-DATA - avoiding the integrity issues inherent with FAT. NTFS
doesn't guarantee data consistency. For that SQL Server relies on the
transaction log. Your transaction logs can and should be placed on
separate drives to avoid disk contention.

"The Windows NT Filesystem (NTFS) is a journaling, or transactional
file system. This means that any I/O that alters the file system data
or meta-data (directory structure, etc.) is completed atomically so
that either all of the changes are completed"
http://www.microsoft.com/technet/arc....mspx?mfr=true

"NTFS does not do data journaling"
http://www.cs.wisc.edu/adsl/Publicat...a-usenix05.pdf

"An important feature of NTFS is journaling. Before a change is made to
the metadata of a file, a transaction is logged in the $LOGFILE."
http://www.mcmillan.cx/ntfs.html

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/m...S,SQL.90).aspx
--

Aug 7 '06 #14
boa
* David Portas wrote, On 07.08.2006 20:33:
Bjørn Augestad wrote:
>>
I'm no NTFS expert either, so I read the tech spec for NTFS at
http://technet2.microsoft.com/Window....mspx?mfr=true

Here's a quote:
NTFS Change Journal

As files, folders, and other NTFS objects are added, deleted, and
modified, NTFS enters change journal records in streams, one for each
volume on the computer.

My interpretation, hopefully wrong, is that NTFS journal entries will be
written to disk whenever a file is modified. This will lead to disk head
movement and decreased performance on a busy disk, won't it?
[snip]
>
"NTFS does not do data journaling"
http://www.cs.wisc.edu/adsl/Publicat...a-usenix05.pdf
Excellent, that's exactly what I needed to know. Thanks. So standard
NTFS is what I'll use.

While we're at it, any thoughts on the registry setting
NTFSDisableLastAccessUpdate?
Bjørn

[snip]
Aug 7 '06 #15

"boa" <bo*****@gmail.comwrote in message
news:mq********************@telenor.com...
>
While we're at it, any thoughts on the registry setting
NTFSDisableLastAccessUpdate?
None other than you're probably over thinking the problem.

Seriously, any performance gains, etc. you're almost certainly better off
looknig elsewhere.

>
Bjørn

[snip]

Aug 8 '06 #16
Greg D. Moore (Strider) wrote:
"boa" <bo*****@gmail.comwrote in message
news:mq********************@telenor.com...
>>While we're at it, any thoughts on the registry setting
NTFSDisableLastAccessUpdate?


None other than you're probably over thinking the problem.

Seriously, any performance gains, etc. you're almost certainly better off
looknig elsewhere.
Sorry if I've given you the impression that we're not looking elsewhere.
Right now we are 5 guys rewriting queries and client applications, as
well as adding memory, servers, more spindles and everything else that
may improve performance, and the profiler and dta runs 24/7(Almost...).

Maybe it's just me, but I enjoy knowing these things, and if MSFT added
NTFSDisableLastAccessUpdate(aka unix noatime) I presume they did it for
a reason. It would be nice to know that reason ;-)

Bjørn
>
>>Bjørn

[snip]


Aug 8 '06 #17

"Bjørn Augestad" <bj************@gmail.comwrote in message
news:eb**********@bat-news01.banetele.basefarm.net...
Greg D. Moore (Strider) wrote:
"boa" <bo*****@gmail.comwrote in message
news:mq********************@telenor.com...
>While we're at it, any thoughts on the registry setting
NTFSDisableLastAccessUpdate?

None other than you're probably over thinking the problem.

Seriously, any performance gains, etc. you're almost certainly better
off
looknig elsewhere.

Sorry if I've given you the impression that we're not looking elsewhere.
Right now we are 5 guys rewriting queries and client applications, as
well as adding memory, servers, more spindles and everything else that
may improve performance, and the profiler and dta runs 24/7(Almost...).

Maybe it's just me, but I enjoy knowing these things, and if MSFT added
NTFSDisableLastAccessUpdate(aka unix noatime) I presume they did it for
a reason. It would be nice to know that reason ;-)
I can definitely understand curiousity. :-)
My point is simply that any performance gains here are probably miniscule
compared to what you can make elsewhere.

>
Bjørn

>Bjørn

[snip]

Aug 9 '06 #18
On Wed, 09 Aug 2006 02:18:46 GMT, "Greg D. Moore \(Strider\)"
<mo****************@greenms.comwrote:
>My point is simply that any performance gains here are probably miniscule
compared to what you can make elsewhere.
I would add that exploring settings that are not commonly used is an
opportunity to discover problems that have not yet been found.

There are no magic bullets.

Roy Harvey
Beacon Falls, CT
Aug 9 '06 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: tiacux | last post by:
Tech Associates is recruiting for: A SQL Server Database Systems Administrator for Jacksonville, Florida. Salary to $75,000. Description The Database Systems Administrator's role is to...
9
by: Water Cooler v2 | last post by:
There are two datatypes for storing binary data type in the SQL Server: 1. binary - for fixed length binary data 2. varbinary - for variable length data My question is: how is data inserted...
4
by: AlexDP | last post by:
My program has to access an SQL Server DB file that is in the same folder as the executable. i dont want to setup a server. i was able to do this on my own computer, the program would access any...
9
by: dotnetfellow | last post 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"...
2
by: Jobs | last post by:
Download the JAVA , .NET and SQL Server interview with answers Download the JAVA , .NET and SQL Server interview sheet and rate yourself. This will help you judge yourself are you really worth of...
14
by: Developer | last post by:
Hello All, i have recently installed VS2005 and was trying to install SQL sever 2000. I have Win XP' SP2. But when I tried installing, it only installed client tools and not the database. Can...
0
Coldfire
by: Coldfire | last post by:
Since i cannot show the differences in a two-column like table. I am first putting MS SQL Server 2005 and then MySQL 5.x. MS SQL Server 2005 Brief Overview - SQL Server is a full-fledged...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.