473,325 Members | 2,342 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,325 software developers and data experts.

Code in the database or middle tier (the CLR controversy)

There doesn't seem to be consensus about when to put code in the
database or in the middle tier. There was a long discussion about this
in an Oracle newsgroup (message ID:
UL**************@nwrddc02.gnilink.net).

Elsewhere there's been discussion about Microsoft SQL Server 2005
adding the CLR to support stored procedures in languages such as C#. A
scan of the Web and discussion forums finds differing opinions about
this.

Two authors have written articles that fall on different sides of the
debate.

"Keys to the Database"
http://www.intelligententerprise.com...cleID=50500830

"SOA, Multi-Tier Architectures and Logic in the Database"
http://www.sqlsummit.com/Articles/Lo...heDatabase.HTM

Joe Celko wrote the first article, but his objections point to
Microsoft SQL Server 2005:

"I have an article at WWSUG.com on how much I hate the CLR stuff that
Microsoft is putting out."
http://blog.intelligententerprise.co...es/002419.html

"The bad news is that SQL Server 2005 will you define your own
aggregate
functions in a CLR language."
Message id: 41*************************@posting.google.com

IBM DB2 and Oracle are doing the same thing with the .NET CLR. Is this
a non-issue or are all three companies misguided?

Jul 23 '05
62 4042
Erland Sommarskog wrote:
Except that you might try learning ANSI join syntax.

Here I don't agree with Daniel, and I will have to say that I was
surprised to see his dismay for this syntax. Then again, it took me
some time to start appreciate it. But it might be that Oracle's
proprietary operator for outer join (+= or whatever it is) is less
horrible than SQL Server's old *=.


Consider these two INNER JOINS formatted to match.

-- ISO syntax
SELECT p.last_name, t.title_name
FROM person p , title t
WHERE p.title_1 = t.title_abbrev;

-- ANSI syntax
SELECT p.last_name, t.title_name
FROM person p INNER JOIN title t
ON p.title_1 = t.title_abbrev;

Line 2:
What advantage in replacing a single
comma with "INNER JOIN"?

Line 3:
What value in replace WHERE with ON

If performance is identical? The issue is not much
different from asking which is better, a car with
the steering on the right or a car with the steering
on the left.

Now I know those used to the ANSI syntax will likely
be thinking compatibility with other systems. But
those with 10+ years in Oracle will be thinking: So
what!
--
Daniel A. Morgan
http://www.psoug.org
da******@x.washington.edu
(replace x with u to respond)
Jul 23 '05 #51
DA Morgan (da******@psoug.org) writes:
Consider these two INNER JOINS formatted to match.

-- ISO syntax
SELECT p.last_name, t.title_name
FROM person p , title t
WHERE p.title_1 = t.title_abbrev;

-- ANSI syntax
SELECT p.last_name, t.title_name
FROM person p INNER JOIN title t
ON p.title_1 = t.title_abbrev;

Line 2:
What advantage in replacing a single
comma with "INNER JOIN"?

Line 3:
What value in replace WHERE with ON
In this example: not very much. But digest this:

FROM notes nte, insloannotes iln, contnotes con, instruments ins,
trades trd, accounts acc, customers cst, addresses adr,
customeraddresses cad, insloanstartnotes ils, countries cou,
notprintedcontnotes npc
WHERE nte.nteid = npc.conid
AND npc.printdate IS NULL
AND nte.nteid = iln.conid
AND iln.loanconid = con.conid
AND nte.trdid = trd.trdid
AND con.insid = ins.insid
AND iln.loanevent = 'I'
AND iln.loanconid = ils.conid
AND nte.accno = acc.accno
AND acc.cstno = cad.cstno
AND acc.cstno = cst.cstno
AND cad.isdefaultsendout= 1
AND cad.adrid = adr.adrid
AND adr.coucode = cou.coucode
AND trd.butcode = 'IIL'
AND (trd.tradedate BETWEEN @busdatefrom AND @busdateto OR
(@busdatefrom IS NULL AND @busdateto IS NULL))
AND (con.accno = @accno OR @accno IS NULL)

versus:

FROM notprintedcontnotes npc
JOIN notes nte ON nte.nteid = npc.conid
JOIN trades trd ON trd.trdid = nte.trdid
JOIN insloannotes iln ON nte.nteid = iln.conid
JOIN contnotes con ON con.conid = iln.loanconid
JOIN insloanstartnotes ils ON con.conid = ils.conid
AND iln.loanconid = ils.conid
JOIN instruments ins ON con.insid = ins.insid
AND trd.insid = ins.insid
JOIN accounts acc ON nte.accno = acc.accno
AND con.accno = acc.accno
JOIN customers cst ON acc.cstno = cst.cstno
JOIN customeraddresses cad ON acc.cstno = cad.cstno
AND cad.isdefaultsendout = 1
JOIN addresses adr ON adr.adrid = cad.adrid
LEFT JOIN countries cou ON adr.coucode = cou.coucode
WHERE npc.printdate IS NULL
AND iln.loanevent = 'I'
AND trd.butcode = 'IIL'
AND (trd.tradedate BETWEEN @busdatefrom AND @busdateto OR
(@busdatefrom IS NULL AND @busdateto IS NULL))
AND (nte.accno = @accno OR @accno IS NULL)

I know which one I rather have for breakfast.
If performance is identical? The issue is not much
different from asking which is better, a car with
the steering on the right or a car with the steering
on the left.
On SQL Server, the performance is indeed identical. The story is the
query processor rewrites the query internally. Obviously, I cannot
tell what Oracle does.
Now I know those used to the ANSI syntax will likely
be thinking compatibility with other systems. But
those with 10+ years in Oracle will be thinking: So
what!


Actually, as long as we are into inner joins, both syntaxes are
ANSI-compatible. It is when it comes to outer joins it matter.
Here both SQL Server and Oracle have their own propritary operators.
I don't know about the Oracle operator, but the *= in SQL Server
is very problematic. For this reason, there is a strong recommendation
to use ANSI JOIN for outer joins, and once you are there, it's logical
to use it for inner joins as well. But this is for SQL Server. If
the Oracle outer-join operator (+= is it?) is sounder, you certainly
have one incentive less to change.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 23 '05 #52
Erland Sommarskog wrote:
In this example: not very much. But digest this:

FROM notes nte, insloannotes iln, contnotes con, instruments ins,
trades trd, accounts acc, customers cst, addresses adr,
customeraddresses cad, insloanstartnotes ils, countries cou,
notprintedcontnotes npc
WHERE nte.nteid = npc.conid
AND npc.printdate IS NULL
AND nte.nteid = iln.conid
AND iln.loanconid = con.conid
AND nte.trdid = trd.trdid
AND con.insid = ins.insid
AND iln.loanevent = 'I'
AND iln.loanconid = ils.conid
AND nte.accno = acc.accno
AND acc.cstno = cad.cstno
AND acc.cstno = cst.cstno
AND cad.isdefaultsendout= 1
AND cad.adrid = adr.adrid
AND adr.coucode = cou.coucode
AND trd.butcode = 'IIL'
AND (trd.tradedate BETWEEN @busdatefrom AND @busdateto OR
(@busdatefrom IS NULL AND @busdateto IS NULL))
AND (con.accno = @accno OR @accno IS NULL)

versus:

FROM notprintedcontnotes npc
JOIN notes nte ON nte.nteid = npc.conid
JOIN trades trd ON trd.trdid = nte.trdid
JOIN insloannotes iln ON nte.nteid = iln.conid
JOIN contnotes con ON con.conid = iln.loanconid
JOIN insloanstartnotes ils ON con.conid = ils.conid
AND iln.loanconid = ils.conid
JOIN instruments ins ON con.insid = ins.insid
AND trd.insid = ins.insid
JOIN accounts acc ON nte.accno = acc.accno
AND con.accno = acc.accno
JOIN customers cst ON acc.cstno = cst.cstno
JOIN customeraddresses cad ON acc.cstno = cad.cstno
AND cad.isdefaultsendout = 1
JOIN addresses adr ON adr.adrid = cad.adrid
LEFT JOIN countries cou ON adr.coucode = cou.coucode
WHERE npc.printdate IS NULL
AND iln.loanevent = 'I'
AND trd.butcode = 'IIL'
AND (trd.tradedate BETWEEN @busdatefrom AND @busdateto OR
(@busdatefrom IS NULL AND @busdateto IS NULL))
AND (nte.accno = @accno OR @accno IS NULL)

I know which one I rather have for breakfast.
And I'd likely agree. But then I wouldn't use this query as
a demo of EXPLAIN PLAN for what should be equally obvious reasons.
Actually, as long as we are into inner joins, both syntaxes are
ANSI-compatible. It is when it comes to outer joins it matter.
Here both SQL Server and Oracle have their own propritary operators.
Not true. Oracle has for multiple versions now allowed either ANSI or
ISO syntax. --
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp


--
Daniel A. Morgan
http://www.psoug.org
da******@x.washington.edu
(replace x with u to respond)
Jul 23 '05 #53
DA Morgan wrote:
Erland Sommarskog wrote:
In this example: not very much. But digest this:
<snip> Actually, as long as we are into inner joins, both syntaxes are
ANSI-compatible. It is when it comes to outer joins it matter.
Here both SQL Server and Oracle have their own propritary operators.

Not true. Oracle has for multiple versions now allowed either ANSI or
ISO syntax.

Not his point. The point is that the prorietary synatx also has
proprietary semantics. So why teach what Oracle discourages?
Interesting to note that Oracle bothered. Apparantly they saw a need
for compliance for core function...
http://download-west.oracle.com/docs...queries006.htm
Quote:
Oracle recommends that you use the FROM clause OUTER JOIN syntax rather
than the Oracle join operator. Outer join queries that use the Oracle
join operator (+) are subject to the following rules and restrictions,
which do not apply to the FROM clause OUTER JOIN syntax:

*

You cannot specify the (+) operator in a query block that also
contains FROM clause join syntax.
*

The (+) operator can appear only in the WHERE clause or, in the
context of left-correlation (that is, when specifying the TABLE clause)
in the FROM clause, and can be applied only to a column of a table or view.
*

If A and B are joined by multiple join conditions, then you must
use the (+) operator in all of these conditions. If you do not, then
Oracle Database will return only the rows resulting from a simple join,
but without a warning or error to advise you that you do not have the
results of an outer join.
*

The (+) operator does not produce an outer join if you specify
one table in the outer query and the other table in an inner query.
*

You cannot use the (+) operator to outer-join a table to itself,
although self joins are valid. For example, the following statement is
not valid:

-- The following statement is not valid:
SELECT employee_id, manager_id
FROM employees
WHERE employees.manager_id(+) = employees.employee_id;
However, the following self join is valid:

SELECT e1.employee_id, e1.manager_id, e2.employee_id
FROM employees e1, employees e2
WHERE e1.manager_id(+) = e2.employee_id;

*

The (+) operator can be applied only to a column, not to an
arbitrary expression. However, an arbitrary expression can contain one
or more columns marked with the (+) operator.
*

A WHERE condition containing the (+) operator cannot be combined
with another condition using the OR logical operator.
*

A WHERE condition cannot use the IN comparison condition to
compare a column marked with the (+) operator with an expression.
*

A WHERE condition cannot compare any column marked with the (+)
operator with a subquery.

If the WHERE clause contains a condition that compares a column from
table B with a constant, then the (+) operator must be applied to the
column so that Oracle returns the rows from table A for which it has
generated nulls for this column. Otherwise Oracle returns only the
results of a simple join.

In a query that performs outer joins of more than two pairs of tables, a
single table can be the null-generated table for only one other table.
For this reason, you cannot apply the (+) operator to columns of B in
the join condition for A and B and the join condition for B and C.
Please refer to SELECT for the syntax for an outer join.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Jul 23 '05 #54
DA Morgan (da******@psoug.org) writes:
Erland Sommarskog wrote:
Actually, as long as we are into inner joins, both syntaxes are
ANSI-compatible. It is when it comes to outer joins it matter.
Here both SQL Server and Oracle have their own propritary operators.


Not true. Oracle has for multiple versions now allowed either ANSI or
ISO syntax.


I think you misunderstood. I don't question that Oracle has the LEFT
JOIN operator and that. What I was trying to say is that it could be the
case that Oracle's own outer-join operator is not as tainted as the
one of SQL Server, and thus the incentive to use the ANSI syntax would
not be as strong.

But judging from Serge Rideau's post, there are problems with (+)= as well.
Although the *= of SQL Server could still be worse. As a matter of fact,
in SQL 2000, *= will only be available in compatibility mode only.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 23 '05 #55
Serge Rielau wrote:
Not his point. The point is that the prorietary synatx also has
proprietary semantics. So why teach what Oracle discourages?
Normally I encourage that students, and professionals, follow Oracle's
advice. For example when Oracle said stop using LONG and LONG RAW I
dropped every example that used them.

But there is a significant difference with the ISO syntax and here is
why.

1. 99% of all code in Oracle anyone sees will be ISO compliant and the
Oracle professional must understand it and be able to maintain it.

2. In the Oracle community those that code with ANSI are generally
viewed as newbies who have recently come over from some other
product. Use ANSI in an interview and likely you won't get the job
if the other person that applied is your technical equal but uses
the syntax that looks more "normal" to the interview team.

And while I expect you won't like #2, your liking it is not relevant to
the fact that I have seen this played out in multiple interviews.

There are things the Oracle supported ANSI syntax will do, such as full
outer joins that are far more complex to do with ISO. And there are
things the ANSI syntax allows that are just plain moronic ... such as
natural joins. I encourage all of my students to learn all of it and
then use the appropriate tool for the environment in which they are
working.
Interesting to note that Oracle bothered. Apparantly they saw a need for
compliance for core function...
http://download-west.oracle.com/docs...queries006.htm


They seem to always embrace that which is common. But also to extend
where they see a 'need' (you may read that as 'market opportunity').
The critical factor is that I can accomplish the goal in the manner that
is most pleasing to me as a developer. The amount of ANSI code I have
seen in Oracle applications is a very small percentage: Not more than a
few percent. That may change over decades but it isn't changing any time
soon.
--
Daniel A. Morgan
http://www.psoug.org
da******@x.washington.edu
(replace x with u to respond)
Jul 23 '05 #56
Erland Sommarskog wrote:
DA Morgan (da******@psoug.org) writes:
Erland Sommarskog wrote:
Actually, as long as we are into inner joins, both syntaxes are
ANSI-compatible. It is when it comes to outer joins it matter.
Here both SQL Server and Oracle have their own propritary operators.
Not true. Oracle has for multiple versions now allowed either ANSI or
ISO syntax.

I think you misunderstood. I don't question that Oracle has the LEFT
JOIN operator and that. What I was trying to say is that it could be the
case that Oracle's own outer-join operator is not as tainted as the
one of SQL Server, and thus the incentive to use the ANSI syntax would
not be as strong.


I misunderstood. You are correct in your assumption.

SQL> SELECT DISTINCT i.srvr_id
2 FROM serv_inst i, servers s
3 WHERE i.srvr_id = s.srvr_id(+);

11 rows selected.

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=11 Bytes=88)
1 0 SORT (UNIQUE) (Cost=6 Card=11 Bytes=88)
2 1 NESTED LOOPS (OUTER) (Cost=5 Card=999 Bytes=7992)
3 2 TABLE ACCESS (FULL) OF 'SERV_INST' (TABLE) (Cost=4
Card=999 Bytes=3996)
4 2 INDEX (UNIQUE SCAN) OF 'PK_SERVERS' (INDEX (UNIQUE))
(Cost=0 Card=1 Bytes=4)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
11 consistent gets
0 physical reads
0 redo size
532 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
11 rows processed

SQL> SELECT DISTINCT i.srvr_id
2 FROM serv_inst i LEFT OUTER JOIN servers s
3 ON i.srvr_id = s.srvr_id
4 /

11 rows selected.

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=11 Bytes=88)
1 0 SORT (UNIQUE) (Cost=6 Card=11 Bytes=88)
2 1 NESTED LOOPS (OUTER) (Cost=5 Card=999 Bytes=7992)
3 2 TABLE ACCESS (FULL) OF 'SERV_INST' (TABLE) (Cost=4
Card=999 Bytes=3996)
4 2 INDEX (UNIQUE SCAN) OF 'PK_SERVERS' (INDEX (UNIQUE))
(Cost=0 Card=1 Bytes=4)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
11 consistent gets
0 physical reads
0 redo size
532 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
11 rows processed

As you can see: Identical.
But judging from Serge Rideau's post, there are problems with (+)= as well.
Although the *= of SQL Server could still be worse. As a matter of fact,
in SQL 2000, *= will only be available in compatibility mode only.


Serge is incorrect in that these limitations have always been there and
Oracle developers have been using in-line views to work around them for
so long that they don't even pay any attention: It just comes naturally.

I can't speak for Oracle but I expect the ISO operators will be there
for the rest of my professional life. Oracle has always been far more
committed to backward compatibility than some other companies. Often to
my dismay in that some of the antiquities encourage bad practices.
--
Daniel A. Morgan
http://www.psoug.org
da******@x.washington.edu
(replace x with u to respond)
Jul 23 '05 #57
DA Morgan (da******@psoug.org) writes:
As you can see: Identical.
For such a simple query, I would expect anything else. I did not try
the same on SQL Server, but I would expect identical plans there as well.

The problems with *= are not really with performance, but funny
restrictions, and unexpected results that are difficult to explain. And
there is no *=* for a full outer join.
I can't speak for Oracle but I expect the ISO operators will be there
for the rest of my professional life. Oracle has always been far more
committed to backward compatibility than some other companies. Often to
my dismay in that some of the antiquities encourage bad practices.


Microsoft has in my opinion a quite elegant take on this: you can run a
database in compatibility mode for an earlier version. This permits
MS to drop support or to make incompatible changes in order to improve
things, but still makes it possible for people to migrate.

I have seen few people lament that *= are going away from the mainstream.
In our system we had over 500 stored procedures with this syntax, and I
really welcome the change. (And thanks to that I outlawed the syntax in
our load tool, our numbers have now started to decrease.)

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 23 '05 #58
Erland Sommarskog wrote:
Microsoft has in my opinion a quite elegant take on this: you can run a
database in compatibility mode for an earlier version. This permits
MS to drop support or to make incompatible changes in order to improve
things, but still makes it possible for people to migrate.


I'm not sure I'd use the phrase "quite elegant" as it is just a copy of
functionality available in all commercial RDBMS products.

For example Oracle, in its init.ora (now compilable as the spfile), has
a parameter called compatible that can be set to a wide range of
previous versions. That parameter has existed longer than SQL Server.
--
Daniel A. Morgan
http://www.psoug.org
da******@x.washington.edu
(replace x with u to respond)
Jul 23 '05 #59
DA Morgan wrote:
Serge Rielau wrote:

Are programmers using PL/SQL on the app side any smarter w.r.t.
relational SQL than those using VB? Do they write better SQL because
they use PL/SQL?

Yes. Yes. Yes.


LOL

I'm using SQL in PERL, am I a bad person now?
I've used PL/SQL client side, and I found it to be tough, I was much
more busy with the language elements than creating fast, optimized SQL.
Perl is a really sloppy (not inefficient though) language, you don't
have to think (about the language) while coding, put some nice SQL in it
though.

-R-
Jul 23 '05 #60
DA Morgan (da******@psoug.org) writes:
I'm not sure I'd use the phrase "quite elegant" as it is just a copy of
functionality available in all commercial RDBMS products.

For example Oracle, in its init.ora (now compilable as the spfile), has
a parameter called compatible that can be set to a wide range of
previous versions. That parameter has existed longer than SQL Server.


OK, I didn't know that. Thanks for the information.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 23 '05 #61
Jurgen Haan wrote:
DA Morgan wrote:
Serge Rielau wrote:


Are programmers using PL/SQL on the app side any smarter w.r.t.
relational SQL than those using VB? Do they write better SQL because
they use PL/SQL?


Yes. Yes. Yes.


LOL

I'm using SQL in PERL, am I a bad person now?
I've used PL/SQL client side, and I found it to be tough, I was much
more busy with the language elements than creating fast, optimized SQL.
Perl is a really sloppy (not inefficient though) language, you don't
have to think (about the language) while coding, put some nice SQL in it
though.

-R-


Post some of your complex SQL statements if you'd like to find out
what others think.

But if you read my comments closely you would have noted that much of
my concern was that these people would then blur the line into designing
schemas, creating tables, indexes, and likely few if any constraints.

And yes I am painting with an extremely broad brush. A few will write
good code: I think the vast majority will trash the environment in which
they are working.
--
Daniel A. Morgan
http://www.psoug.org
da******@x.washington.edu
(replace x with u to respond)
Jul 23 '05 #62
Serge Rielau wrote:
DA Morgan wrote:
William Stacey [MVP] wrote:
But your talking design now. That has nothing to do with SQLCLR
integration. I don't see the DB design process changing just because
of SQLCLR. You will still have DBAs/ DB architects doing that work
(or should). The app guys are still going to be the app guys. You
need both. So nothing has changed in that regard.

This isn't a new concept or untested technology. Oracle and DB2 have
supported Java database plug-ins (e.g., UDFs, stored procedures) since
the late '90s (DB2 UDB ver 5.1 and Oracle 8.1.4).
If you take a look at the procedural constructs of each of these SQL
"extensions" you can mess things up equally fine as with VB, Java or C#.
.. Do they write better SQL because they use PL/SQL?


If there was a pattern of systemic failures, database corruption or
security problems due to database extensions written in a programming
language, Oracle and IBM would know by now. There have been several
major releases since Java in the database emerged in 1997.

If allowing non-SQL database extensions were a serious product design
flaw, we'd see IBM, Oracle, Sybase and Microsoft taking a different
tack. They've embraced the Java VM and .NET CLR because they provide
better server stability than older technology, such as writing extended
stored procedures in C.

The potential for harm isn't so much a question of which tool to use as
who should be doing the work. It's obvious you should not use someone
to develop VB, C# or Java database extensions if he/she isn't normally
trusted with production database work, such as creating stored
procedures with PL/SQL or T-SQL.

The guideline I've expressed for eight years about Java in the database
applies also to the CLR issue:

"When it comes to developing SQL database extensions, it's better to
take a database person and teach him/her Java then to to assign the
task to someone who knows Java but lacks database expertise."

The same applies to working with the CLR for extending databases,
whether they're DB2, Oracle or Microsoft SQL Server. Don't use Java, VB
or C# skills as the primary basis for deciding who's writing database
extensions.

Ken North
======================
http://www.SQLSummit.com
http://www.GridSummit.com
http://www.WebServicesSummit.com

Jul 23 '05 #63

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

Similar topics

62
by: SAN3141 | last post by:
There doesn't seem to be consensus about when to put code in the database or in the middle tier. There was a long discussion about this in an Oracle newsgroup (message ID:...
0
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...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
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: 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
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
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.